Policy Enforcement Point

Embedding authoritative policy into each Agent implementation easily leads to inconsistent enforcement; the alternative is to separate policy decisions from framework-specific execution, but a key requirement is that the runtime must not offer an alternative path that bypasses enforcement.

Instructions in a prompt are not an authorization system; the operator, the resource and the permitted actions should be checked in the tool wrapper at the last moment before execution, high-impact actions should require human approval, and read and write capabilities should be separated wherever possible.

In engineering practice, the control point is usually called the Policy Enforcement Point (PEP), paired with the Policy Decision Point (PDP); the PEP sits on the link between the agent and the tools (such as a tool gateway, an MCP server proxy, or unified tool-call middleware) and is responsible for asking the PDP whether a call is allowed before each call is issued and allowing or denying it accordingly.

The three dimensions of identity, tool scope, and task context must be passed in at the PEP as structured fields, transferring the judgment from the model to a policy engine rather than letting the model judge on its own.

The key significance of putting the decision in the PEP rather than the prompt is that a 'policy' in the prompt is advice for the model to read, which the model may ignore, misunderstand, or be bypassed into via injection, whereas the PEP is a mandatory checkpoint on the code path that the model cannot bypass.

The control point for access control should be located on the request path between the agent and the tools, not in the prompt, system message, or policy document.

The core value of an external policy layer lies in its non-bypassability — even if the agent code is tampered with or subjected to a prompt injection attack, it can still serve as the last line of defense.