As large language models become capable of operating across enterprise systems, the security implications of their decisions extend far beyond generated text. An agent connected to privileged tools can read confidential records, modify business data, execute database operations, deploy software, change access permissions, and initiate financial transactions. In these environments, a model's output is no longer merely a suggestion. It can become an instruction that changes the state of a real system.
This creates a fundamental architectural problem: an LLM can generate a technically valid tool call that is operationally useful but unauthorized. The call may conform to the tool's schema, satisfy the model's interpretation of the task, and appear entirely reasonable while violating a tenant boundary, exceeding a permission scope, bypassing an approval requirement, or targeting a resource the initiating user is not allowed to modify.
The central challenge is not to eliminate every incorrect decision made by a model. It is to ensure that an incorrect or manipulated decision cannot independently acquire the authority to execute.
The problem with asking an agent to respect its own boundaries
Agentic systems are commonly constrained through system prompts, tool descriptions, behavioral instructions, and model-level safety mechanisms. These controls are useful for guiding behavior, but they operate within the same probabilistic reasoning process that generates the actions being controlled.
An instruction such as "never modify production resources without authorization" does not prevent the model from generating a production modification request. It only attempts to influence whether the model chooses to generate that request.
The distinction becomes particularly important when agents consume untrusted information. An email, retrieved document, issue description, repository file, or API response can contain instructions that attempt to redirect the agent toward an unauthorized operation. Even if the model is explicitly instructed to ignore such instructions, the application cannot assume that every future model invocation will interpret them correctly.
The same problem exists without an adversary. Models can misunderstand the scope of a task, infer permissions that were never granted, confuse a requested outcome with authorization to perform every intermediate action, or generate arguments that refer to the wrong resource.
Consider an agent asked to resolve outstanding invoices. It may correctly identify an invoice discrepancy but then decide to modify the invoice, approve the payment, and initiate a transfer. Each operation may appear to advance the original objective. None is automatically authorized by the request to resolve discrepancies.
The security failure occurs when the system treats the agent's interpretation of its objective as sufficient authority to execute the resulting operations.
A model should be responsible for proposing actions, not for determining the limits of its own authority.
Separating action generation from action authorization
A safer architecture separates the reasoning layer from the authorization layer. The LLM generates a proposed operation, while a deterministic enforcement mechanism independently evaluates whether that operation is permitted under the application's security rules.
This separation requires a specific placement in the execution path. Authorization must happen after the model has produced the tool name and arguments, but before the underlying tool begins its protected operation.
Checking permissions only when a conversation starts is insufficient because the application does not yet know which action the model will select, which resource it will target, or which arguments it will supply. Similarly, determining that an agent is generally allowed to use an invoice tool does not establish permission to approve a particular invoice.
The authorization decision must apply to the actual invocation.
A secure execution path therefore looks like this:
User Request
|
v
LLM Reasoning and Planning
|
v
Generated Tool Name + Arguments
|
v
Deterministic Tool Gateway
|
+--> Validate Tool and Argument Schema
|
+--> Resolve Trusted Principal and Delegation
|
+--> Resolve Authoritative Resource Attributes
|
+--> Construct Authorization Request
|
v
Cedar Policy Evaluation
|
+---------------------+
| |
v v
DENY ALLOW
| |
v v
Reject Invocation Execution Guard
|
v
Protected Tool / API
|
v
Downstream Controls
The gateway is not another reasoning agent. It does not need to understand why the model believes an action is useful. It needs to determine whether the requested operation satisfies a defined set of authorization conditions.
If authorization is denied, the invocation is rejected. If the policy engine cannot produce a valid decision, execution does not proceed. A natural-language explanation from the model cannot override either outcome.
This is the distinction between a behavioral restriction and an enforcement boundary. Behavioral restrictions attempt to influence which actions an agent proposes. An enforcement boundary determines which proposed actions the surrounding system permits to execute.
Why deterministic policy enforcement matters
A security boundary should not change its decision merely because the model rephrases an argument, claims that an action is urgent, or generates a more convincing justification. The decision should follow from the authenticated principal, requested action, target resource, applicable policy, and trusted authorization context.
This is where policy-as-code becomes valuable.
Instead of distributing authorization logic across prompts, tool descriptions, and individual application handlers, the system expresses permissions as explicit, reviewable rules. The application constructs a structured request, and a policy engine evaluates that request against the applicable rules.
The separation also makes the authorization model easier to test. A policy can be evaluated against authorized and unauthorized principals, different resource states, boundary values, and adversarial requests without relying on the LLM to behave in a particular way.
Determinism alone, however, does not guarantee security. A deterministic policy can consistently make the wrong decision if its rules are incorrect or its inputs are untrustworthy. The objective is to make authorization explicit, independently enforceable, and testable—not to assume that formal policy evaluation eliminates every implementation defect.
Using Cedar as the authorization layer
Cedar is an authorization policy language designed to separate access-control decisions from application business logic. Its authorization model evaluates the principal requesting an operation, the action being requested, the resource being accessed, and the relevant context.
These concepts map naturally onto agentic tool execution.
The principal identifies the authenticated actor or workload whose authority is being exercised. The action identifies the specific operation, such as reading an invoice, approving a payment, modifying a repository, or deploying a service. The resource identifies the actual target. The context supplies additional trusted facts required to determine whether the operation is permitted.
For example, an enterprise might allow a finance agent to read invoices across a permitted business unit while restricting invoice approvals to a particular tenant, a defined monetary threshold, and invoices in a pending state.
Those conditions should not be inferred by the model at runtime. They should be expressed as explicit authorization policies and evaluated against authoritative application data.
Cedar supports permit and forbid policies. An applicable forbid policy takes precedence over a matching permit, while a request without an applicable permit is denied by default. This provides a useful foundation for expressing both positive permissions and explicit prohibitions.
A simplified policy might look like this:
permit (
principal == Escepine::Agent::"finance_agent",
action == Escepine::Action::"invoice:approve",
resource is Escepine::Invoice
)
when {
principal.tenant == resource.tenant &&
resource.status == "pending" &&
resource.amount <= principal.approval_limit
};
This illustrative policy grants approval authority only when the specified principal, action, resource type, tenant relationship, invoice state, and approval threshold satisfy the rule. The entity types and attributes must be defined in a corresponding Cedar schema and populated through trusted application logic.
The important property is that the model cannot expand the permission by adding an argument such as "approved": true, claiming administrator privileges, or explaining why the transaction should be allowed. Those claims are not authorization grants.
Cedar policies can be stored in version-controlled .cedar files, reviewed independently of the agent's prompts, and validated against the application's authorization schema. This creates a more explicit security model in which permission changes can be reviewed, tested, and deployed as security-sensitive code changes.
The authorization request must be constructed from trusted facts
Placing a Cedar evaluation between argument generation and execution is necessary, but the quality of that evaluation depends on the request constructed by the application.
LLM-generated arguments are untrusted input. The model may propose a resource identifier, transaction amount, tenant identifier, or approval status, but the presence of a value in the tool call does not establish that the value is authoritative.
The gateway must validate the arguments against the tool's schema, resolve the authenticated principal independently, and retrieve security-relevant resource attributes from the appropriate source of truth.
For example, if the model requests approval of invoice INV-2048, the gateway should resolve the invoice's actual tenant, current status, and authoritative amount before constructing the policy request. It should not simply trust the model to supply those facts correctly.
This distinction is essential because a policy engine evaluates the facts it receives; it does not independently establish their authenticity.
A secure implementation also binds the authorization decision to the operation that will execute. If the gateway authorizes one invoice but the executor later resolves a different invoice, the policy boundary has been undermined. The same applies if an authorized amount, beneficiary, destination, or resource identifier changes after evaluation.
The authorization layer and executor must therefore operate on the same validated request and resource binding. Where the resource state can change between authorization and execution, the application should recheck the relevant conditions or use transactional controls, version checks, and conditional operations to prevent stale authorization from being reused.
Why the gateway must be impossible to bypass
A policy file is not an enforcement mechanism by itself. It becomes one only when every protected operation is required to pass through the policy decision.
If an agent invokes one tool through the guarded gateway but another tool calls a privileged API directly, the second path can defeat the entire architecture. The same vulnerability can appear through background workers, retries, delegated agents, asynchronous jobs, alternate API routes, or newly registered tools that do not inherit the same restrictions.
The execution architecture must therefore make authorization mandatory rather than optional.
Protected tool implementations should not expose unguarded privileged clients to the model runtime. Tool registration should enforce the required authorization path, and application tests should verify that denied requests cannot reach the protected executor. Downstream services should also enforce their own authentication and access-control rules so that bypassing the gateway does not automatically confer unrestricted authority.
For high-stakes workflows, this should be treated as an architectural invariant: no supported path from an LLM-generated tool call to a protected side effect may bypass the enforcement boundary.
Failures must also be handled explicitly. An unavailable policy engine, invalid policy request, unresolved identity, missing required attribute, or policy evaluation error must never be silently translated into permission. The application must reject the operation whenever it cannot establish a valid authorization decision.
This fail-closed behavior can reduce availability during failures, but it prevents uncertainty from becoming an implicit grant of authority.
Authorization is not the same as approval
Not every action that satisfies an authorization policy should execute immediately. Some operations require additional workflow controls, particularly when they involve irreversible changes, significant financial value, privileged access, or production infrastructure.
A policy might establish that a finance agent is allowed to initiate payments up to a defined threshold. A particular transaction may still require a human approver, a separation-of-duties check, or confirmation that the beneficiary and amount match an independently approved transaction.
These requirements should be represented in trusted application state and enforced by the execution workflow. The model's claim that a human approved the action is not sufficient evidence.
Approval should be associated with the specific operation and its material arguments. If the amount, beneficiary, target resource, or other security-relevant field changes, the application must determine whether the previous approval remains valid. When it does not, the action must be reauthorized or sent through the appropriate approval process again.
The same principle applies to long-running agentic workflows. An authorization decision made at the beginning of a task should not automatically authorize every subsequent action. Permissions can change, resource states can change, and the agent's plan can evolve. Each consequential invocation must be evaluated against the authority applicable to that invocation.
Measuring whether the boundary actually works
The effectiveness of this architecture cannot be established by checking that .cedar files exist or that a policy engine returns the expected result in isolation. The complete execution path must be tested.
A useful test suite should verify that an authorized request reaches the intended executor, while a denied request produces no protected side effect. It should also cover cross-tenant access, invalid arguments, fabricated approval claims, threshold violations, unknown tools, missing identity attributes, policy-engine failures, and resource changes between authorization and execution.
Adversarial tests should deliberately attempt to manipulate the model into proposing prohibited operations. The objective is not to prove that the model resists every attack. It is to demonstrate that the enforcement layer continues to reject unauthorized actions even when the model proposes them.
The same tests should exercise retries, delegated tool calls, background execution, and alternate entry points. Otherwise, a system may appear secure during ordinary tool use while retaining an unguarded route to the same privileged operation.
Operational monitoring should distinguish authorization decisions from execution outcomes. Recording the principal, action, resource, policy version, decision, and execution status makes it possible to investigate denied requests and identify failures in the enforcement path without relying exclusively on model-generated explanations.
The most important invariant is straightforward: a denied, invalid, or indeterminate authorization request must not produce the protected side effect.
How Escepine Approaches Agentic Authorization
Escepine approaches agentic security by treating authorization as an execution-time invariant rather than a behavioral instruction given to an LLM. The objective is to ensure that model-generated intent cannot directly translate into privileged operations without passing through an independently enforced, deterministic policy boundary.
At the center of this approach is a mandatory authorization funnel positioned after the LLM generates its tool name and arguments, but before the corresponding tool executes. The application validates the proposed arguments, resolves the authenticated principal and authoritative resource attributes, and evaluates the resulting authorization request against version-controlled .cedar policy files. Only an explicitly authorized request may proceed to the protected execution path; denied, invalid, or indeterminate requests must be rejected.
This separation allows the agent to retain flexibility in planning and tool selection without allowing its reasoning process to determine its own permissions. Prompt injection, hallucinated approvals, misleading tool arguments, and persuasive justifications must not be capable of overriding the policy decision. Each consequential tool invocation is evaluated against the permissions applicable to that specific action and resource, rather than inheriting unrestricted authority from the original user request or a previous successful invocation.
The enforcement boundary is only as strong as its implementation. Escepine's architectural objective therefore extends beyond policy definition to complete mediation: protected tools must not expose alternative execution paths that bypass authorization, resource identity must remain bound between evaluation and execution, and policy-engine failures must never become implicit permission. For high-impact operations, this boundary can be complemented by execution-time state verification, explicit human approval, and independent authorization in downstream services.
The underlying principle is that the LLM controls the proposal, while deterministic application code controls whether the proposal is allowed to become an action. By separating probabilistic reasoning from operational authority, Escepine's approach aims to make agentic workflows more controllable, auditable, and suitable for environments where unauthorized execution is unacceptable.
Check out: https://escepine.vercel.app/
Building agentic systems around explicit authority
Escepine's approach focuses on this separation between model-generated intent and enforceable operational authority. By placing deterministic authorization checks between LLM argument generation and tool execution, and expressing permissions through version-controlled Cedar policy files, the architecture aims to make security constraints independent of the model's interpretation of its instructions. Achieving this requires a complete enforcement path, trusted identity and resource resolution, fail-closed behavior, execution-time validation, and independent downstream controls—not simply the presence of policy files.
The broader principle is that agent autonomy and unrestricted authority are not the same thing. An enterprise can allow an agent to plan complex tasks, select tools, and adapt its strategy while still restricting the operations it can execute. The model does not need to become perfectly reliable for the surrounding system to enforce a reliable authorization boundary.
An LLM may propose an action, but the authority to execute that action must remain outside the LLM.
Top comments (3)
The line about the model being responsible for proposing actions but not for determining the limits of its own authority captures the whole problem in one sentence. Cedar-style policy-as-code also gives you something prompts never will: a versioned, testable record of what was allowed when. One thing I am curious about: when the policy engine itself is unreachable at runtime, do you fail closed or degrade gracefully?
Well, it depends based on the criticality of the tasks,
The ideal solution will be if the policy engines is unreachable than the workflow should be parked and informing the human, and will resume and pick up the state from the exact point, and if the issues resolved and policy engine back online, it funnels through it
Parking the workflow and resuming from the exact state when the policy engine comes back online is a clean, principled answer to the unreachable-policy problem.