Architects designing where agent authorization is evaluated and where it is enforced.
Where the decision is made, where it is applied, and what happens when the two are separated by a network.
The control gap
The split is simple to state: the decision point decides, the enforcement point applies. It goes wrong in practice in two ways. The enforcement point is placed after the side effect, so it can report but not stop. Or the decision point is unreachable and the enforcement point has no defined behaviour, so it either fails open silently or takes the whole workflow down. Both failures are architectural and neither is visible in a happy-path demo.
What good looks like
Enforcement sits in the request path before the external call, the decision point is consulted with full context, and the behaviour when they cannot reach each other is written down and tested.
- Put the enforcement point before the side effect. After the call, you have monitoring, not enforcement.
- Send the decision point everything it needs in one request: agent, delegated user, action, resource, arguments, environment.
- Define fail-closed and fail-open per action class rather than globally, and test both paths.
- Cache decisions only where the inputs are stable, and honour revocation faster than the cache lifetime.
A production workflow
- Identify every point in the agent runtime where an external side effect is initiated.
- Wrap each one so the decision is requested before execution and the result gates the call.
- Measure decision latency at the real call rate and set a timeout with defined behaviour.
- Exercise the outage path deliberately, including a revocation issued during an outage.
Evidence to require
- The decision request and response for each call, including latency.
- Calls that executed under a cached decision, and the cache age at execution.
- Behaviour during a decision-point outage, per action class, from a real test.
- Any enforcement point that logged an action it did not gate, which is a design gap rather than a bug.
Buyer checklist
- Is enforcement genuinely before the side effect, or does it observe the result?
- What does each action class do when the decision point times out?
- How long can a stale allow survive a revocation?
- Are there paths in the agent runtime that reach a tool without passing an enforcement point?
Practical answers
Common implementation questions
Can the decision point live in the same process?
It can, and that removes latency and an outage mode. The trade is deployment coupling: policy changes then ship with the application. Both designs are defensible; what is not defensible is leaving the outage behaviour undefined.
Is an API gateway an enforcement point?
It is one, for what it can see. If the gateway can read the action and the target from the request, it can enforce on them. If the action is a tool name inside a protocol body, the gateway needs to understand that protocol or it is enforcing on the wrong thing.
How does AuthZEN relate to this?
AuthZEN standardises the request and response between the enforcement point and the decision point, so the two can come from different vendors. Endram exposes an AuthZEN-compatible evaluation endpoint for exactly that reason.