Security and data handling

This page covers what SecureAuth Agent Authority verifiably does to protect stored credentials and account for every action — not a compliance checklist. For certification status (SOC 2 and similar), contact your SecureAuth account team.

Credential encryption at rest

Resource credentials — OAuth tokens and any other secrets stored for a connection — are encrypted at rest with AES-256-GCM. Each ciphertext is bound to its organization through authenticated associated data (AAD), so a value that decrypts successfully in one organization's context can't be replayed in another's.

The encryption layer supports key rotation: it holds one current key for new writes and tries any number of previous keys in turn when decrypting, so a key can be rotated without re-encrypting or invalidating credentials written under the old one.

Encryption in transit

The gateway serves traffic over TLS, terminating it itself rather than relying on a proxy to do it. OAuth redirect targets are validated before use: anything that isn't https is rejected, as are protocol-relative URLs and any host outside the gateway's own service domain or its configured allow-list.

Organization isolation

Every request resolves to exactly one organization from the host it arrived on — your organization's slug is the leading label of the service domain — and that organization is carried through the request. Data access is scoped to it: repository reads and writes take the organization as a parameter, so one organization's records are not addressable from another's request. The AAD binding described above is the same boundary enforced a second time at the encryption layer, so even a leaked ciphertext won't decrypt in another organization's context.

Per-user credentials

The gateway calls every catalog resource — Slack, GitHub, Jira, and the rest — using the requesting user's own connection, never a pooled or shared service account. Each user only reaches what their own account can see, actions are attributed to the right person in the upstream service, and revoking one user's connection affects only that user. See Per-user isolation.

The exception is custom resources configured with API Key or OAuth2 client-credentials authentication: those credentials are set once on the resource and used for every user who calls it, so upstream attribution is per-resource, not per-user. (A custom resource using the OAuth2 authorization-code grant is per-user, like the catalog.) The audit log still records which user and agent made each call.

What the audit log stores

Every audit log entry is structured event metadata: a timestamp, the actor (user and agent instance), the action type, the resource involved, and action-specific details such as tool name or policy effect. Every entry also carries the request context it was made from — IP address, approximate location (city and country), device, OS, browser, user agent, and a trace ID.

It does not store the raw prompt or response text of an agent's underlying conversation with its LLM — only the record of the gateway call itself: who made it, what it targeted, and what the policy engine decided.

Audit events are retained for 3 months, then dropped automatically. LLM telemetry follows the same 3-month retention.

Response redaction

Data Protection response filters rewrite sensitive text — SSNs, API keys, email addresses — out of a tool's response before it reaches the agent. Redaction runs inside the gateway, so the sensitive values never leave it. The audit record of a redacted call stores the rule names that matched and how many spans each replaced — never the matched or redacted text itself. If a filter's pattern can't be compiled at request time, the gateway fails closed and blocks the call rather than forwarding an unredacted response.

Region-scoped service domains

The gateway itself is served from a region-specific service domain, with your organization's slug as the leading host label; the OAuth callback substitutes oauth for that label. Gateway-to-resource traffic goes to each provider's own endpoint, but some providers require allow-listing the gateway's callback origin on their side. Atlassian, for example, requires allow-listing https://oauth.aisecurity.services.<region>.connect.secureauth.com/** — see Atlassian's dynamic client registration setup for your region's value and the full steps.

Next steps

• Connections — how per-user credentials are established and revoked.
• Audit log — the full field list and how to filter it.
• Credential modes — choose which OAuth app issues the credentials this page describes.
• Data Protection — write the response filters that redact sensitive data on the way out.