Where Should Authorization Actually Happen in an Agentic System? Security Thinking at the Execution Boundary

A Security Boundary That's Been Overlooked

When building agentic systems, one question keeps coming up — yet rarely gets examined closely: Where should authorization checks actually happen?

A developer on Reddit raised this pointed question. They observed that many mainstream architectures follow a seemingly sensible flow: the model decides what action to take, a policy check happens upstream, and the executor trusts that result and proceeds directly with execution.

Intuitively, this design makes sense — separation of concerns, each component doing its job. But what the author zeroes in on is precisely that final boundary: the last step before a side effect is produced. Should the executor independently verify that the action it's about to execute is still authorized, still temporally valid, and hasn't been replayed?

Why Upstream Checks Aren't Enough

Putting authorization upstream is common practice — it centralizes management and keeps the logic clean. But agentic systems introduce complexity that traditional applications simply don't have.

Model decisions are dynamic and not fully predictable. Between when a policy check passes and when the executor actually carries out an action, there's a time window. Within that window, several things can go wrong:

• State drift: Authorization was valid at check time, but by execution time, permissions may have been revoked. An approved transfer action, if delayed, could execute against an account whose state or permissions have already changed.
• Action tampering: If upstream only validated the "action type," but the executor receives specific parameters, tampering at any intermediate layer could cause the actual executed action to diverge from the one that was authorized.
• Replay attacks: The same authorization token that passed a check, if not constrained to single use, could be reused to trigger multiple unintended side effects.

In other words, an upstream check answers the question "is this type of action permitted?" — but the execution boundary needs to answer: "is this specific action, right now, still legitimate and unique?" These are two fundamentally different questions.

Replay Attack is a classic network security threat: an attacker intercepts a valid authorization message and retransmits it later to trick the system into executing the same operation again. In traditional web applications, this is naturally mitigated through HTTPS and session tokens. But in agentic systems, authorization tokens are often passed between internal services through longer chains with more intermediate steps, which widens the replay window considerably. Defenses include attaching monotonically increasing sequence numbers to tokens, binding requests to the requester's identity fingerprint (such as IP or Agent ID), and the simplest solution — a one-time nonce (Number Used Once), where each authorization credential carries a random string that the server marks as consumed upon use, rejecting any subsequent request with the same nonce. For irreversible side effects (transfers, deletions, external API writes), introducing a nonce mechanism is essentially a zero-cost guarantee of idempotency.

The Defense-in-Depth Approach

The author's core argument — that executors should independently verify — is fundamentally an application of the classic security principle of defense in depth to agentic architecture.

No single layer should be the sole source of trust. The upstream policy engine handles coarse-grained authorization decisions, while the executor, as the layer closest to actual side effects, should bear the responsibility for final integrity verification.

In practice, this typically means combining several mechanisms:

Binding Actions to Authorization Credentials

An authorization credential shouldn't just authorize an action "type" — it should be bound to the complete content of a specific action (parameters, target, context). When the executor validates the credential, it simultaneously verifies that the action about to be executed matches the action that was specified when the credential was issued, preventing parameter substitution.

One practical technical implementation is to use HMAC or digital signatures on authorization credentials: when the policy engine issues a credential, it serializes the complete action description (method name, parameter list, target resource, timestamp, nonce) and includes it within the signature scope. The executor, upon receiving the credential, re-serializes the action it's about to execute and verifies the signature — if any parameter was modified in transit, even by a single byte, signature verification will immediately fail. This approach is conceptually similar to JWT (JSON Web Token), but whereas JWT typically carries identity claims, here we need to lock in the "specific action intent" within the signature to truly prevent action tampering. When implementing this, pay attention to deterministic serialization to avoid legitimate requests being falsely flagged due to differences in field ordering or whitespace.

Freshness Checks

Introduce short TTLs or timestamps for authorization, and have the executor confirm the credential hasn't expired before executing. For high-risk operations, you can even require re-confirmation of current permission status at execution time, rather than relying on a snapshot from check time.

Anti-Replay Mechanisms

Introduce a unique nonce or one-time token for each authorization, and have the executor track consumed credentials to reject duplicate requests. This is especially critical for irreversible side effects involving money, deletion, or external API writes.

Defense in Depth originates from military strategy, referring to the use of multiple independent lines of defense to erode an attacker's ability to advance, rather than relying on a single strong barrier. Brought into information security, its core assumption is that "any single defense mechanism can be bypassed" — so systems should be designed such that even if one layer fails, subsequent layers can still prevent damage from spreading. In software architecture, a common manifestation is the coexistence of network-layer firewalls + application-layer input validation + database-layer access controls, rather than relying on just one. Mapping this principle to agentic systems: the Policy Engine is analogous to the perimeter firewall, responsible for coarse-grained intent filtering; the Executor, sitting right next to real-world side effects, is analogous to the innermost database access control, responsible for precise final verification just before "pulling the trigger." The two defensive layers have different responsibilities and different failure modes — their combination yields far greater overall robustness than either layer alone.

The Trade-off: Security vs. Latency

This design isn't without costs. Having the executor independently verify means extra computation, additional state queries, potential latency, and increased system complexity.

A sensible approach is risk-tiered authorization. For read-only, reversible, low-impact actions, trusting upstream checks may be sufficient. But for actions that produce real-world side effects, are irreversible, or involve sensitive resources, independent verification at the execution boundary becomes essential. The greater an agentic system's autonomy and the larger the impact of its actions, the more valuable this boundary becomes.

Why This Matters Especially in the Agentic Era

In traditional software, action sequences are hardcoded by developers — paths are predictable, and authorization can be reasoned about statically. But in agentic systems, it's the model that decides at runtime what to do. That autonomy is precisely where the value lies — and precisely where the risk lives.

When an AI agent can autonomously invoke tools, access data, and execute operations, the gap between "the model decided on an action" and "the action was executed safely" must be bridged by architecture. Putting the last line of defense in the executor is an acknowledgment of reality: even the most perfect upstream decision needs to be confirmed one more time at the moment of execution.

This Reddit discussion was brief, but it hit on a real and unresolved pain point in agentic security architecture. As agent capabilities grow, "where should authorization happen" will no longer be an academic question — it will be an engineering decision that every team deploying autonomous agents must answer.