Agent door

Anomaly alerts

The agent door watches every grant for four unusual patterns and emails your organization's owners and admins when it sees one. This page explains what each alert means and what to do about it.

Every call an agent makes through the door is recorded against the capability grant it is using. The door watches that record for four patterns worth a human look, and when it finds one it notifies the owners and admins of the organization that issued the grant — nobody else, and never another workspace.

These are detection alerts, not enforcement. An anomaly never throttles, suspends, or revokes anything on its own. The door keeps serving the grant exactly as before, and the decision about what to do is yours. That is deliberate: an automatic cut-off would make a false positive an outage.

What to do first

Nearly every alert resolves with one question: can you account for what the agent was doing?

1. Read the grant name in the alert. It tells you which agent integration the alert is about. If it reads as a short handle like #a1b2c3d4, that grant has no label — see Label your grants.
2. Check the timing against your own changes. A deploy, a new automation, a key rotation, or someone on your team connecting a new client is the usual explanation.
3. Open the Activity tab in Agent Oversight and look at what the grant actually called around that time. Activity shows the agent's runs and the individual tool calls inside them.
4. If you cannot account for it, revoke the grant from Agent Oversight → Grants. Revoking is the containment action; it costs you an integration you can re-issue, and it costs an attacker everything the grant carried.

Revocation is one-way. A revoked grant cannot be un-revoked — restoring the integration means issuing a new grant and pointing the agent at it. That is worth knowing before you click, but it is not a reason to hesitate when you genuinely cannot explain the activity.

Revocation is fast, not instantaneous. A new session can never be established against a revoked grant, and a session already running is cut off at its next authority re-check — within about a minute. A call or two may still land in that gap. If you believe the identity provider itself is compromised rather than one integration, revoking the trusted issuer in Agent Oversight → Issuers is the larger hammer: it takes down every grant that issuer vouches for.

The four alerts

Each alert arrives with the subject prefix [Agent Door] and one of the four titles below.

Unknown client on an agent grant

Subject: [Agent Door] Unusual agent activity: unknown client on an agent grant

What it means. A client identity that has never used this grant before just presented it. A grant is normally held by exactly one client, so a second one appearing is the signal that a credential has been shared, copied, or stolen. The identity is the pair of the client id and the issuer that vouched for it — the same client id asserted by a different trusted issuer counts as a different party, because it is one.

This is the alarming one. Of the four, it is the alert most likely to mean someone other than you is using your grant.

Usually caused by: a legitimate second integration being pointed at an existing grant instead of getting its own; a client being re-registered with your identity provider under a new id; or a genuinely unauthorized party holding the grant.

What to do: if you did not connect a new agent client, revoke the grant. If you did, note that the clean pattern is one grant per client — separate grants let you revoke one integration without breaking the others.

Agent key rotation on an agent grant

Subject: [Agent Door] Agent key rotation on an agent grant

What it means. A client this grant already knows presented a new Demonstrating Proof-of-Possession (DPoP) signing key. DPoP binds a session to a key the client proves it holds; this alert says the key changed, not that the client did.

This is routine key hygiene, not an intrusion signal. It has its own name and its own notification setting precisely so that ordinary key churn does not sit in the same pile as an unknown client and teach you to ignore both.

Usually caused by: an agent rotating its keypair on schedule; a client redeploying and generating a fresh key; or a development script that makes a new key each run.

What to do: normally nothing. If the client is not one you expect to be rotating keys, treat it with the same seriousness as an unknown client and review the grant. If a particular integration rotates keys constantly and the alerts are noise, mute this alert type on its own — see below — without going blind to the unknown-client alert.

Tool-call spike

Subject: [Agent Door] Unusual agent activity: tool-call spike

What it means. One grant made an unusually large number of tool calls in a short period — far more than an agent going about normal work.

Usually caused by: an agent stuck in a retry or reasoning loop; a backfill or bulk job someone kicked off without warning you; or a session being drained by someone who should not have it.

What to do: check whether a job of yours was running. If the volume is not yours, revoke the grant. Note that this alert is separate from rate limits — the limits are hard caps that reject calls, while this alert is a heads-up that the traffic looks unlike the grant's normal behaviour. You can get one without the other.

Repeated capability denials

Subject: [Agent Door] Unusual agent activity: repeated capability denials

What it means. A grant repeatedly tried to use tools outside the capabilities it holds, and was refused every time. Nothing got through — the capability gate did its job — but a pattern of denials is worth seeing, because it is what probing for access looks like.

Usually caused by: a misconfigured agent that assumes it has permissions it was never given; an integration written against a broader grant than the one it was issued; or something deliberately mapping the edges of what the grant can reach.

What to do: work out which tools were being attempted. If it is your own agent overreaching, either narrow what it tries or widen the grant deliberately — a grant is edited in Agent Oversight → Grants, one capability at a time. If you cannot place the agent, revoke.

Who receives them, and how

• Recipients are the grant's own organization owners and admins. Members do not receive them. An alert is scoped to the organization that issued the grant, so it can never reach another workspace.
• Both channels, by default. Every one of the four arrives as an email and as an in-app notification linking to Agent Oversight. They are on by default on both channels because they are security alerts.
• Everyone who receives an alert can act on it: owners and admins are exactly the roles that can edit and revoke grants.

Turning them down

Both are tunable per person at Settings → Notifications, on either channel, as two separate controls:

• Agent anomaly alerts — covers the unknown-client, tool-call-spike, and capability-denial alerts.
• Agent key rotation — covers key rotation only.

That split is the useful one: you can silence routine key churn and still be told when an unknown client shows up. The reverse is also true, and worth being deliberate about — muting Agent anomaly alerts silences the unknown-client alert along with the two noisier ones, and there is no way to keep one of those three and drop the others. If the spike or denial alerts are the problem, the better fix is usually to sort out the agent causing them.

Preferences are per user, so muting your own does not mute your colleagues'.

Filtering them in your inbox

Every agent-door alert email carries the literal prefix [Agent Door] in its subject, so a mail rule on that string catches the whole family and nothing else. The rest of the subject is one of the four titles above, which lets you route the routine key-rotation mail somewhere quieter than the other three.

Label your grants

Alerts name the grant by its label. If a grant has no label, the alert falls back to a short id handle like #a1b2c3d4, which tells you far less at the moment you most want to know which integration is involved. Labels are set when a grant is issued and can be edited any time in Agent Oversight → Grants; giving each grant a name you would recognise in an email is a minute well spent.

Limits worth knowing

• A grant's first-ever session never raises an unknown-client alert. There is no prior history to compare it against, so the first session is what establishes the baseline. Provisioning a new grant is quiet by design.
• A burst is one email, not one per identity. If several new clients or rotated keys appear close together on the same grant, you get one notification of that kind for that grant rather than a flood. The cap is on how often you are woken, not on what is detected — each distinct identity is still recorded on our side. Combined with the next point, that means a burst tells you that something unusual happened without listing every identity involved; ask us if you need the full list.
• There is no alert history screen yet. Agent Oversight shows approvals, grants, issuers, and activity, but it does not currently list past anomaly alerts. The email and the in-app notification are your record of an alert, so keep them; the Activity tab is where you go to see what the grant actually did.
• Agent Oversight is an Enterprise and Agency feature. If your workspace cannot reach the console, it cannot reach the agent door either — see the agent door overview.