SeeCodes Security Posture

Security and data isolation designed for enterprise trust.

Granting a tool access to source code and project management data requires absolute trust. SeeCodes uses Forge-managed Jira App access, strictly single-use Jira request keys, one-time IDE launch codes, task-scoped permits, and short-lived task storage so the execution path stays bounded and auditable.
Forge-managed authUS / EU / UK regions48-hour task purge
Privacy policyAPI referenceSubmit an issue

On this page

6 sections

Infrastructure & Hosting

The backend runs entirely on AWS using managed services and regional isolation options.

AWS Cloud

SeeCodes is hosted on Amazon Web Services and uses managed services such as API Gateway, Lambda, DynamoDB, and S3 that comply with SOC 1, SOC 2, and SOC 3 standards.

Regional Isolation

Administrators can choose to process and store data in the US, EU (Stockholm), or UK (London).

Data Encryption

Encryption is applied both in transit and at rest.

In transit

All traffic between the IDE, Jira, and the backend is protected with TLS 1.2 or higher.

At rest

Persistent configuration and telemetry data, along with temporary task uploads, are encrypted at rest with AES-256 via AWS KMS.

Data Retention & Ephemerality

SeeCodes minimizes the footprint of proprietary code on the service.
  • Short-lived task artifacts: selected source files, uploaded task inputs, AI outputs, and generated diff bundles are written only to the temporary task bucket for the active run.
  • Automatic deletion: the temporary run bucket is purged automatically within 48 hours of task completion.
  • No permanent raw repository mirror: SeeCodes does not keep a long-lived full clone of your repository as part of the normal task execution path.
  • Project index caching is limited to per-file hashes and AI-generated explainer summaries used for context reuse, not a full checkout or a permanent archive of run payloads.

Authentication & Authorization

Access control follows the Jira trust boundary, uses strictly enforced single-use request-key rotation, and separates browser-facing launch from permit-scoped IDE execution.

Forge-managed Jira App access

The Jira App authenticates with a Forge bearer token and rotates a single-use Jira backend request key through /v1/jira/request-key, X-SeeCodes-Jira-Request-Key, and X-SeeCodes-Next-Request-Key. The server rejects the request unless that key is the current unexpired key bound to the same tenant/session context.

One-time launch codes and task permits

The Jira App mints a one-time launch code through /v1/security/vscode-link. After the IDE opens, the extension exchanges that code through /v1/security/launch-exchange for the actual task-scoped bearer permit used on /v1/tasks/* and /v1/projects/*/indexes/* routes. The server rejects launch exchange unless the code is unused, unexpired, and still bound to the exact projectId/taskId pair that was minted.

  • Browser-facing launch links expire after the configured 1 to 14 day window if unused. On the first successful IDE exchange, the embedded launch code is consumed immediately, and the exchanged task permit is shorter-lived (24 hours).
  • Jira request-key rotation has strict replay semantics: each key is one-time-use, short-lived, tenant/session-bound, invalidated after successful use, and consumed with race-safe handling so only one concurrent request can win.
  • Task permits are scoped to a single Jira task, and the server rejects requests unless the path taskId, path/query projectId, and any runId all resolve to that same bound task.

Hard authorization invariants

The server rejects requests unless any presented projectIdexactly matches the permit's bound projectId, the path taskId exactly matches the permit's bound taskId, and any runId belongs to that same bound task.

AI Model Privacy

SeeCodes routes model calls through secure, business-to-business integrations.

Zero training policy

Source code, prompts, and Jira data are never used by underlying AI providers to train their public or foundational models.

AI requests are routed through managed B2B model integrations. Customer code, prompts, Jira data, and generated task artifacts are not used to train public models.

Vulnerability Management

Operational access is restricted and the delivery pipeline includes automated checks.
  • Automated dependency scanning and static application security testing (SAST) are part of the CI/CD pipeline.
  • Production infrastructure access is limited to authorized eprojac engineers using SSO, MFA, and audited bastion hosts.

Enterprise procurement

If you need security questionnaires or additional architectural detail, contact security@seecodes.com.