Sprintloom builds and operates the Auto-Triage AI app for Atlassian Jira. This Security Policy describes how we manage security across our app, infrastructure, and related services — including the SprintLoom hosted LLM inference endpoint at autotriage-api.sprintloom.com.
This policy applies to:
The Auto-Triage AI Atlassian Forge app
The SprintLoom hosted LLM proxy and inference infrastructure
All supporting systems, dashboards, and internal tooling
2. Security Incident Handling
2.1 Incident Response Process
Security incidents are handled through the following process:
Detection: Automated monitoring on all SprintLoom infrastructure detects anomalous activity, failed authentication attempts, and unusual API traffic patterns.
Triage: Incidents are classified by severity within 1 hour of detection. Severity levels:
Critical: Active breach, data exfiltration, or service-wide outage — immediate response (< 1 hour)
High: Potential breach or significant service degradation — response within 4 hours
Medium: Non-critical vulnerability or limited impact — response within 24 hours
Low: Informational, no active risk — response within 48 hours
Containment: Affected systems are isolated. Credentials are rotated if suspected compromised.
Notification: Affected customers are notified within 72 hours per GDPR/data breach notification requirements.
Remediation: Root cause analysis is performed and fixes are deployed.
Post-mortem: A written incident report is produced within 14 days and shared with affected customers on request.
2.2 Contact for Security Issues
If you discover a security vulnerability or believe an incident has occurred, contact us immediately:
All SprintLoom infrastructure is scanned for vulnerabilities on a recurring basis. This includes:
Dependency scanning: Automated checks for known vulnerabilities in dependencies (e.g., npm audit, Snyk, or equivalent)
Container scanning: Docker images and container runtimes are scanned for OS-level vulnerabilities
Network scanning: Periodic scans for open ports, misconfigured services, and exposed endpoints
3.2 Patch Management
Security patches are applied on the following schedule:
Critical vulnerabilities (CVSS 9+): Patched within 48 hours of disclosure
High vulnerabilities (CVSS 7–8.9): Patched within 14 days
Medium/Low vulnerabilities: Addressed in next scheduled maintenance window
3.3 Penetration Testing
SprintLoom conducts periodic security assessments against its public-facing infrastructure. Critical findings are prioritized and remediated before the next release cycle.
4. Security Controls
4.1 Access Controls
SSH access to production servers is restricted to authorized personnel via key-based authentication only (no password-based SSH)
Multi-factor authentication (MFA) is required for all internal accounts
Least-privilege: Each service and user account has the minimum permissions required
Access is reviewed quarterly and revoked when personnel leave or change roles
API keys and credentials are stored in Atlassian Forge encrypted storage — not in source code or environment files
4.2 Infrastructure
LLM inference runs on a dedicated VPS with no shared infrastructure from other customers
Upstream Ollama server is protected by nginx with Basic Auth, accessible only from authorized proxies
Cloudflare Tunnel exposes the inference endpoint over HTTPS with Bearer token authentication
Server logs are retained for a maximum of 7 days for debugging purposes only
No data is stored in databases beyond the active inference session
5. Encryption & Data in Transit
HTTPS only: All connections to autotriage-api.sprintloom.com use TLS 1.2 or higher. Cleartext HTTP is rejected.
Bearer token authentication: API requests require a Bearer token. Tokens are scoped per-customer installation and stored in Atlassian Forge encrypted storage.
Upstream encryption: Traffic from the SprintLoom proxy to the upstream Ollama server uses HTTPS (via nginx reverse proxy with TLS termination).
No hardcoded credentials: No secrets, API keys, or tokens are present in source code. All credentials are injected via environment variables at deployment time.
Data in transit is not persisted: Issue content is received, processed in memory for inference, and discarded immediately. Nothing is written to disk.
6. Data Storage & Access
Atlassian Forge Storage: App configuration (LLM endpoint URL, model selection, field toggles, label mappings) is stored in Atlassian Forge's encrypted key-value storage. Customers can delete this data at any time via the admin UI reset function.
No persistent LLM data: Jira issue summaries and descriptions are sent to the LLM inference endpoint for processing only. No issue content is written to disk or retained after inference completes.
Short-term logs: Infrastructure logs may contain request metadata (timestamps, endpoint, token ID) for up to 7 days. Logs do not contain full issue descriptions or Jira credentials.
No cross-tenant data access: Each customer's installation is isolated. Credentials are scoped per installation.
7. Prompt Injection Defenses
Auto-Triage AI implements multiple layers of protection against prompt injection attacks:
Structural isolation: Ticket content is wrapped in delimiter markers (### TICKET START / ### TICKET END ###) to separate it from system instructions
Schema validation: LLM output is validated against an allowlist before any Jira update is applied. Unknown keys are stripped; invalid priority values are rejected
Input sanitization: HTML tags, script tags, iframes, and event handlers (on*= attributes) are stripped from issue text before it reaches the LLM
Length limits: Descriptions are truncated to 1,000 characters before LLM processing
Jira API validation: All values applied to Jira issues (labels, components, priority) are validated against admin-configured allowlists. Assignee is never set by the AI
8. Atlassian Forge Security
Forge app identity: The app runs within the Atlassian Forge managed runtime, which handles authentication, authorization, and data isolation automatically
Scopes: The app requests only the minimum required OAuth scopes: read/write Jira work, read Jira user, and app storage
No PATs required: The app uses Forge's built-in asApp() and asUser() APIs — no personal access tokens from end users are required or collected
Egress: The app makes outbound HTTPS requests to the configured LLM endpoint only. Wildcard egress is declared in the manifest with a justification for HTTPS enforcement
Admin UI: The React Custom UI is bundled with the Forge app and served from Atlassian's infrastructure — no separate hosting of the admin panel
9. Compliance & Certifications
SprintLoom is committed to maintaining security practices aligned with industry standards. Currently applicable certifications and practices:
GDPR: SprintLoom acts as a data processor for EU customers. A Data Processing Agreement (DPA) is available on request
CCPA: SprintLoom acts as a service provider for California businesses
EEA data transfers: Data processed by SprintLoom's hosted LLM passes through infrastructure in the US. Standard Contractual Clauses (SCCs) or equivalent legal mechanisms apply where required
No data for AI training: No customer data is used to train, fine-tune, or improve any AI model
OpenAI API: If a customer configures their own OpenAI-compatible endpoint, SprintLoom does not control how that provider handles data — customers should review their chosen provider's compliance certifications
10. Contact
For security vulnerabilities, incidents, or questions about this policy:
