Gatekeeper FAQs

Setup and connections

Do I need to remove my existing direct connections?

Yes. The point of Gatekeeper is that your AI client connects to your Gatekeeper gateway instead of connecting to each service directly. If both connections stay in place, your agent can simply route around Gatekeeper and none of your policies apply. Remove the direct connection once the Gatekeeper route is working.

Where do I find my gateway URL?

It's shown in your Gatekeeper dashboard. Each organization has its own unique gateway address, which you configure in your AI client in place of the service's own endpoint.

Which AI tools work with Gatekeeper?

Any client that supports the Model Context Protocol — including Claude, Cursor, and most agent frameworks. Your client connects to Gatekeeper as an MCP server and discovers the available tools through it.

Can I connect a service that doesn't support OAuth?

Yes, though not self-service. Services without an interactive login are connected centrally by an administrator using an API key. See Connection Types.

My agent can't see a tool I know the service has.

That's usually tool enablement rather than policy. Administrators can switch individual tools on and off per service, and a disabled tool doesn't appear to your agent at all. A policy block looks different — it returns a denial with a reason. See Connection Types.

Credentials and data

Can my AI agent see my credentials?

No. Credentials are held encrypted and injected into the request inside Gatekeeper's own infrastructure, after the policy decision and before the call is forwarded. They are never returned to the agent, never displayed, and never written to logs.

What happens to my credentials when I disconnect a service?

Gatekeeper revokes the authorization grant and deletes the stored encrypted credential. Your policies and audit history are retained.

What exactly does Gatekeeper store about my requests?

The audit log retains request metadata and the parameters submitted with each call — which service, which tool, what arguments, when, and the outcome. Response bodies are not retained; the log records only whether the call succeeded.

Worth knowing: because request parameters are retained, anything your agent puts into a request is retained too. If your agent passes descriptive context along with a call, that context is stored in the audit record.

Is Gatekeeper SOC 2 compliant?

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

Is Gatekeeper ready for production use?

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

How long is audit history retained, and can I export it?

[VERIFY]  — Need the retention period and whether export is available. Both come up in nearly every security review, so this answer is worth nailing down.

Policies

What happens if I haven't set any policies?

[VERIFY]  — Depends on the shipped default, which needs confirming. Flagged in the accuracy review: the HubSpot install guide states actions outside policy are denied by default, but a live simulation returned allow from a rule named svc-default . Do not answer this publicly until it's settled.

Can I test a policy without risking anything?

Yes. Gatekeeper can simulate a decision without contacting the service — no action is taken and no audit record is written. You get the outcome, the rule that fired, and the full trail of which layers were consulted. See Testing a Policy Before You Deploy It.

Why was my agent blocked when I granted the permission?

Scopes and policies are separate gates and both have to pass. A scope grant means the action is possible; a policy decides whether it's allowed. Granting write access to a service doesn't override a policy that denies writes.

Can I set different rules for different people?

Yes. Policy is layered across organisation-wide, per-service, per-user, and per-user-per-service chains. Be aware that layer order decides the outcome, not how specific a rule is — see How Policies Are Evaluated.

Why isn't my new rule firing?

Almost always because an earlier layer decided the request first. The first layer that returns a verdict wins, and everything below it is skipped. Simulate the request and look at the trail to see where the decision was actually made.

Can I limit how much an agent does, rather than what it does?

Yes. Policies can see how many requests an agent has made in the last minute and over the current day, and how much data it has moved today. That's enough to require approval past a threshold or deny beyond a daily ceiling.

Can I restrict agent activity to working hours?

Yes — the current timestamp is available to policies, so time-window rules are possible.

Do policy changes apply to actions that were already blocked?

No. A policy change applies to future attempts only. If an action was denied and you've since decided it should be allowed, the agent needs to try again.

Approvals

Who can approve a flagged action?

[VERIFY]  — Need to confirm which roles can approve and whether approvers are configurable per policy.

What happens if nobody approves?

The approval event expires and the held action is discarded — it does not run. Route approval requests somewhere people will actually see them.

Why am I getting duplicate approval requests?

Usually an agent retrying a held action instead of waiting on the original. Each retry creates a new approval event. The agent should poll the existing request rather than re-submitting it.

Does the agent wait while an action is pending?

It should — a correctly implemented client surfaces the approval link and then polls for the result. Once approved, Gatekeeper runs the original request as submitted and returns the result.

Audit and troubleshooting

Can I see what other people's agents have done?

Individual users see their own session activity. Need to confirm whether an organisation-wide administrator view exists.

A service was working and now needs reauthorisation. Why?

Three common causes: the access token expired; someone revoked the app authorisation inside the service itself; or the person who originally connected it lost their own access to that service. Reconnecting resolves all three. If it's the third, reconnect using an account that will keep valid access.

How do I tell a connection problem from a policy block?

Connection problems show against the service — disconnected, or requiring reauthorisation. Policy blocks show against the request, as a denial with a reason. If you're unsure, the audit log entry for the failed attempt tells you which it was.

Something's wrong and I can't work out what.

Start with the audit log entry for the failed attempt — it identifies the service, the tool, the parameters and the outcome. If the outcome is a policy decision, simulate the same request to see which rule and layer produced it. If you're still stuck, contact support with the timestamp of the attempt.