> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atako.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Security
> Agents never have access to your secret keys — ever. How Atako protects every credential you connect.
## The guarantee
**Agents never have access to your secret keys — ever.**
That single invariant is the foundation of every integration on Atako. No agent, no matter how it's prompted, what tools it calls, or what output it produces, can read, print, log, or exfiltrate an API key or OAuth token you've connected. The credential exists in exactly one place: encrypted, on Atako's servers, decrypted only for the fraction of a second it takes to make one outbound call — and never handed to the agent that requested it.
This isn't a policy the agent is asked to respect. It's architectural: the agent's runtime has no code path that can reach a decrypted secret. There is nothing for a prompt injection, a misbehaving tool call, or a compromised dependency to steal.
## How a credential is protected, step by step
The moment you paste an API key or complete an OAuth flow, the secret is encrypted using envelope encryption: a unique data-encryption key (DEK) encrypts the secret with AES-256-GCM, and that DEK is itself wrapped by a key-encryption key (KEK) held in a cloud key-management service (KMS). It is never stored, logged, or displayed in plaintext again — not to any agent, not in an audit log, not even back to the person who entered it.
When an agent decides to use a connected tool, it doesn't touch the credential at all — it sends an *intent*: which connection, which action, and what arguments. It has no mechanism to request, inspect, or receive the underlying key.
Before any call reaches the third-party provider, Atako's platform verifies that a grant exists for that agent and connection, that the requested action is on the grant's allow-list, that the grant's scope covers a read or write action as appropriate (see [Permissions](/integrations/permissions)), and that the submitted arguments are valid. Any failure stops the request right there — nothing is ever sent downstream on a hunch.
Once every check passes, the platform decrypts the secret in memory, injects it into the outgoing request to the provider (as a header or token, never in a URL), and discards the decrypted value immediately after. An anti-SSRF guard ensures the final request URL still resolves to the provider's own official domain, and every outbound call carries a 15-second timeout. The secret exists in decrypted form for the duration of that single call and nowhere else — never in the agent's context, memory, or output.
For OAuth-connected tools, access tokens are refreshed automatically by the platform ahead of expiry — no manual reconnection needed. If a refresh is rejected by the provider, the connection is flagged **error** rather than silently failing, and stays that way until reconnected.
## What actually crosses the wire
```mermaid theme={null}
sequenceDiagram
participant Agent
participant Platform
participant Provider as Third-party provider
Agent->>Platform: Intent: connection + action + arguments
Note over Platform: Grant exists? Action allowed?
Scope sufficient? Arguments valid?
alt Any check fails
Platform-->>Agent: Denied (logged)
else All checks pass
Note over Platform: Decrypt secret in memory
Platform->>Provider: Request, credential injected server-side
Provider-->>Platform: Response
Note over Platform: Discard decrypted secret
Platform-->>Agent: Result only — never the secret
end
```
The secret appears in exactly one hop: from the platform to the provider. It is never present on the arrow between the agent and the platform, in either direction.
## Audit trail
Every call an agent makes through a connection is logged — success, denial, or provider error alike:
| Field | Captured |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Agent, connection, provider, action | What was called, by whom, on which tool |
| Arguments | Logged with sensitive fields redacted — email bodies, search queries, and similar payload contents are never written to the log |
| Status | Allowed and executed, denied by a grant check, or failed at the provider |
| Provider HTTP status | The response code returned by the third party |
| Latency and timestamp | When the call happened and how long it took |
This trail is visible in two places:
* **Per agent** — on the agent's own page, and as events in its [activity timeline](/guides/activity).
* **Company-wide** — a dedicated, admin-only page filterable by team, agent, provider, and date, exportable as CSV up to 50,000 rows, plus an aggregated usage view by provider to spot unexpected or unsanctioned tool use.
## Revocation
Revoking a connection deletes its encrypted secret **immediately and permanently**. There is no recovery, and no grace period: every agent that had access loses it at once, and any future call against that connection fails until it's reconnected with a fresh credential.
Revocation is irreversible by design — it's meant to be the fast, unambiguous way to cut off access the moment you suspect a credential is compromised.
## Related
How connections are set up.
The grant model that decides what an agent is allowed to do before this security layer ever runs.
How the same guarantees apply to an agent working directly in your repositories.
Where per-agent audit events surface day to day.