Solutions
Give security a control point for AI
Workload identity for agents, short-lived credentials, tool restrictions and an investigation trail for when an AI system behaves outside expectations.
What a leak costs
- A leaked API key
- A standing capability. Works until somebody notices, and the scope of the investigation is everything it could reach.
- A leaked grant
- One action, already authorized, already recorded, window closed. A bounded incident rather than an investigation.
Credentials held
10
Held by an agent
0
What security actually needs
A control point, not a dashboard.
Most AI security tooling observes and reports. That is useful and it is not a control — by the time a report exists the action has happened. The thing worth having is a place where a request can be refused before it lands, with an identity attached that the workload could not have minted itself.
Identity is attested, not asserted
A caller claiming to be an agent is not sufficient. The identity has to be provable by something the workload cannot produce for itself, and the method depends on how the system runs:
- orchestrator
- mTLS client cert
- retrieval
- mTLS client cert
- conversational
- OIDC workload token
- scheduled worker
- Platform-signed JWT
This is the load-bearing part. An asserted identity makes every downstream control decorative — if anything can claim to be the refund resolver, the refund resolver’s limits constrain nothing at all.
What it can reach
The agent never receives the credential. It receives a grant.
Scoped to one authorized action, carrying the subject so it cannot be replayed against a different record, and expiring in seconds. That is a property rather than a policy: no endpoint returns a stored credential at any scope, including admin.
The credential vault
10 credentials · 2 due for rotation| Credential | Rotation window | Derived grants | Scopes a grant may carry |
|---|---|---|---|
| RazorpayAPI key | 12/90d | 1 | refund:writepayment:read |
| RazorpayXOAuth client | 51/60d | 1 | payout:create |
| Zoho BooksOAuth client | 34/90d | 1 | journal:write |
| NetSuiteToken pair | 71/90d | 1 | vendor:write |
| SalesforceJWT signing key | 22/180d | 2 | record:write |
| PostgresDB role | 27/30d | 1 | stock:update |
| ZendeskAPI token | 8/90d | 3 | ticket:write |
| GmailDomain-wide delegation | 44/60d | 2 | mail:send |
| Amazon S3IAM role | 5/30d | 0 | dataset:export |
| BoxJWT app | 96/180d | 1 | doc:read |
Credentials held
10
centrally, never distributed
Held by an AI system
0
grants are derived
Due for rotation
2
past 80% of policy age
Rotation stages
4
no outage, no code change
IllustrativeIllustrative figures for the OpsAI sample estate. Two credentials are deliberately past 80% of their window — a vault where everything is always current is a brochure.
Rotation without an outage
4 stages, and the second is the one most procedures omit. Revoking before every enforcement point has accepted the replacement is what turns a routine rotation into an incident.
01
Issue
A second credential is created alongside the first.
02
Dual accept
Both are valid. Every enforcement point takes either one.
03
Cut over
New grants derive from the new credential only.
04
Revoke
The old credential is destroyed at the source.
No code change is needed at any stage, because the AI systems never held the credential in the first place. That is the practical payoff of the vault design rather than a separate feature.
The failure mode nobody designs for
Authority that can be passed on indefinitely cannot be reasoned about.
One agent granting another the ability to act is useful and it compounds. Past the third hop nobody can say whose authority is being exercised, which means nobody can answer the only question that matters after an incident.
Capped at
3
Levels of delegation. The deepest chain in the sample estate currently runs 2 deep, and an attempt to exceed the cap is refused rather than truncated — a truncated chain would silently drop the accountability link.
Multi-agent frameworks make this easy to exceed by accident. A supervisor delegating to a worker that delegates to a tool-caller is three hops before anybody has done anything unusual.
- Every action carries the chain
- From the accountable human down to the acting system, on every attempt. Not reconstructed afterwards, because it cannot be.
- A drop is automatic
- Breaking a bound moves an AI system down a rung immediately. 2 systems in the estate are currently there.
- Delegation cannot widen scope
- A delegated grant is a subset of the delegator’s. There is no path by which a chain accumulates permission it did not start with.
- Why refuse rather than truncate
- Truncating at the cap would let the action proceed with a shortened chain, which looks fine and has quietly lost the link to a person. Refusing is louder and correct.
When something behaves unexpectedly
Detection and containment are separate events, so the gap is a number.
Most incident records collapse them into one entry, which hides the only figure anybody reviewing an incident actually cares about. Keeping them apart is a small decision with a large consequence.
Rate anomaly on payout-runner
detected02:14Forty-one payout attempts in six minutes against a baseline of three an hour. Every individual action inside its bound, which is why no policy refused any of them.
Circuit breaker tripped
contained02:14The agent is stopped rather than refused call by call. Nine seconds after detection, with no human in the path — the breaker is armed because this agent runs unattended.
Retry loop in the upstream workflow
investigated02:31A timeout handler re-queued the same invoice without an idempotency key. The trace for each attempt names the same subject, which is what identified it as one event rather than forty-one.
Idempotency enforced, agent restored
resolved09:05A named person restored the agent after the upstream fix, and after an execution limit was added that would have contained this in three attempts rather than forty-one.
- What you can answer
- What it attempted, what was refused, which rule applied at the time, whose authority it ran under, and how long between noticing and stopping it.
- Why the refusals matter most
- An investigation is mostly about what something tried to do. A log of successful actions cannot answer that, and it is the half most systems discard.
- Replay
- Re-evaluate the action against the rule version in force when it happened, and against a proposed rule to see what would have changed.
Where to start
Ask which AI systems currently hold a long-lived credential.
In most estates the answer is most of them, held in an environment variable, unrotated since the integration was built. That is the exposure worth closing first, and it closes without a code change.