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.

When your agent makes a request:

  1. The request arrives at your gateway and the requester is authenticated.
  2. Policy is evaluated against the request — before any credential is touched.
  3. If the request is allowed, Gatekeeper injects the required secret into the session inside its own trusted infrastructure, with scoped and time-bound permissions.
  4. The request is forwarded to the service.
  5. The response returns to your agent.

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.

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 the credential 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. Disconnecting a service revokes the grant and deletes the stored encrypted credential. Your policies and audit history are retained, so revoking access doesn't cost you your records.

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 over claiming:

  • 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.

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.