Early in the chain
Ordering is the whole design. Evaluated after routing or accounting, revocation would still deny the call but only after work had been done on behalf of an identity that should have had none.
Centralised AI access revocation
A gateway capability that lets an organisation immediately cut off a compromised or disallowed user or agent from downstream AI resources.
- Organisation
- Salesforce / MuleSoft
- Period
- 2025 to Present
- Area
- AI governance
- My role
- Built a gateway policy that evaluates a request's identity against configured blocked identifiers and prevents access to downstream AI resources on a match.
- Result
- An immediate governance mechanism preventing selected identities from invoking protected AI resources, applied centrally instead of application by application.
Context
Access granted through many applications and credentials has to be revocable from one place. When an agent misbehaves or a credential is compromised, the response cannot be a coordinated change across every calling system.
The problem
Revocation needs to take effect immediately and centrally: new requests from a denied identity are refused from the next policy evaluation, before any downstream model call is made. A stream that is already open when access is revoked is a separate case, because the check runs at admission; this write-up makes no claim about cutting off in-flight responses. And the check has to add as little as possible to the requests it does let through.
Constraints
- The check runs on every request, so the allowed path must stay close to free.
- Denial has to happen before any downstream cost is incurred.
- The response must be a clear authorisation error, not an ambiguous failure.
- It has to compose with the rest of the policy chain instead of sitting outside it.
My contribution
Where the work was shared, the list says so.
- Built a gateway policy that evaluates a request's identity against configured blocked identifiers and prevents access to downstream AI resources on a match.
- Worked on its ordering within the wider policy chain and its behaviour for both standard and streaming requests.
Approach
Place the check early in the chain, ahead of resolution and routing, so a denied identity never reaches a provider and never incurs cost.
Keep the policy narrow: identify, compare, deny. A revocation mechanism is only trustworthy if its behaviour is obvious, and breadth here would buy nothing.
Return an explicit authorisation error instead of a generic failure, so the outcome is unambiguous to the caller and to whoever is reading the logs later.
Decisions that mattered
The ones with a real cost on the other side.
Deliberately small
The temptation is to generalise this into a policy engine. A control meant to be reached for in an incident should be simple enough to reason about under pressure.
Outcome
An immediate governance mechanism preventing selected identities from invoking protected AI resources, applied centrally instead of application by application.
What generalises
- Controls used during incidents should be the simplest thing that works.
- Where a check sits in the chain matters as much as what it checks.