How Gatekeeper Protects Your Credentials

The core problem Gatekeeper solves is that giving an AI agent useful access normally means giving it credentials. Once an agent holds an API key, that key is in a context you don't control — it can be logged, echoed into a transcript, or persist in a configuration file long after anyone remembers it's there.

Gatekeeper removes the agent from the credential path entirely.

How it works

Credentials live in Gatekeeper's secrets vault, encrypted at rest. They're released only under policy, and only at the moment of use.

The order is the point. Your agent is authenticated, then policy is evaluated, and only then — if the request was allowed — is a credential released from the vault and injected into the call inside Gatekeeper's own infrastructure, scoped and time-bound.

A denied request never reaches that step, so no credential is released at all.

The agent sends a request and receives a result. It never sees the credential that made the call possible, because injection happens after the policy decision and inside Gatekeeper, not in the agent's context.

What this means in practice

Raw credentials are never exposed to the agent. Long-lived keys aren't handed over, and they aren't copied into plaintext config for the agent to read.

Credentials never appear in logs. Authorization grants are encrypted on receipt. They are not displayed to users, not written to logs, and not transmitted to any AI agent.

Every retrieval is logged. Credential use is recorded in the audit trail alongside the action it enabled — see Reviewing Your Audit Log.

Policies can see credential status without seeing credentials. This one is worth spelling out, because it's a useful proof point. When a policy is evaluated it can read metadata about the credential — whether a refresh token exists, when it expires, which scopes it carries. It cannot read the credential value. That's enough to write a rule like "require approval if the credential expires within the hour" without the policy engine ever handling the secret itself.

Revocation is immediate and complete. Revoking clears the stored credential, and the next call to that service requires fresh consent. Your policies and audit history are retained, so revoking access doesn't cost you your records.

You'll find every grant Gatekeeper holds for you under Sessions → Downstream, with the scopes each one carries and a revoke control per grant. Sessions → Gateway is separate: that revokes an AI client's session rather than a stored credential, which is what you want when the problem is a connected client rather than a service grant.

Credentials held by bots

A bot is a non-human identity that acts without a person present, and it holds its own per-service credentials rather than borrowing yours. Those come in three forms: a delegated OAuth grant you consented to, a token belonging to the bot itself, or an AWS role grant.

The protection model is identical — held in the vault, injected under policy, never exposed. The difference is accountability. A bot's credentials are revocable independently of your own, so cutting off an unattended job doesn't cut off the person who created it.

See Setting Up a Bot for the full picture.

Organization-managed credentials

Some services are connected centrally by an administrator using an API key rather than an interactive login — typically infrastructure and security tooling where per-person authentication isn't practical.

These behave the same way from your agent's perspective: the key is held in the vault, injected under policy, and never exposed. The difference is administrative. You can't adjust the permissions on these connections yourself, because the key's own permissions are fixed at the point it was issued. Broadening access means having the key reissued.

See Connection Types for the full picture.

What Gatekeeper does not protect against

Being clear about the boundary is more useful than overclaiming:

• An over-permissioned credential is still over-permissioned. Gatekeeper controls which actions run, but if the underlying credential grants sweeping access, any action your policy allows inherits that access. Scope the credential tightly as well as the policy.
• Bypass is possible if you leave a direct route open. If your AI client keeps a direct connection to a service alongside the Gatekeeper one, the agent can use it — with no policy check and no audit record. Remove direct connections after cutting over.
• Approved actions are real actions. An action a human approves executes with the same authority as any other. Approval is a control on intent, not a sandbox.
• A permissive default is still a decision. If your org default allows anything no rule matched, credentials will be released for requests you never explicitly permitted. Worth knowing which posture you chose — see How Policies Are Evaluated.

Compliance

Station70 maintains SOC 2 Type 2 compliance, with annual penetration testing and independent cryptography audits. Reports are available at trust.station70.com.

Note that Gatekeeper is currently a pre-release beta, provided without service level commitments and not recommended for high-value, sensitive or mission-critical accounts and data. Review the Gatekeeper EULA before deploying it against anything critical.