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 – Present
Area
AI governance

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, deny before any downstream model call is made, and behave correctly for streaming requests that may already be in flight, all while adding 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

Shared ownership stated as such. Nothing here claims sole authorship of a platform.

  • 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

  1. Place the check early in the chain, ahead of resolution and routing, so a denied identity never reaches a provider and never incurs cost.

  2. Keep the policy narrow: identify, compare, deny. A revocation mechanism is only trustworthy if its behaviour is obvious, and breadth here would buy nothing.

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

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.

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.