Preventing unauthorized agent actions comes down to one principle applied consistently: never let the agent's own judgment be the final word on whether an action is appropriate. An agent's reasoning can be manipulated, mistaken, or simply wrong in ways that look perfectly confident from the outside, so authorization has to be enforced independently of that reasoning, at the point where the action would actually happen. This is a familiar idea from conventional access control, check permissions at the resource, not at the client, applied to a system where the "client" is a language model deciding what to do next based on text it just read.
Authorization has to happen at the tool call, not earlier
A common mistake is building authorization checks into the prompt, instructing the model to "only do X if the user is authorized." That's a suggestion, not a control, because a sufficiently manipulated context can convince the model the condition is met when it isn't. Real authorization has to be enforced outside the model's reasoning path, at the point the tool call is about to execute, using an independent source of truth about what that specific user or agent is actually allowed to do.
Scope tools to the narrowest useful permission
The most effective single change most teams can make is narrowing what each tool is actually capable of. A "update customer record" tool that only accepts a specific set of fields is safer than one that accepts an arbitrary JSON payload and passes it straight to a database write. A tool that can only read is safer than one that can read and write through the same interface. Narrow tools limit what a successful manipulation, or a plain mistake, can actually accomplish, regardless of how it happened.
Bind every action to a specific, real identity
Every tool call should trace back to a specific user, tenant, or service identity whose permissions are being exercised, not a single shared credential the agent uses for everything. Shared, broad credentials are convenient during development and become the reason a security review finds every agent action equally privileged, which defeats the purpose of having granular permissions anywhere else in the system.
Separate read from write, always
Read operations and write operations deserve different default postures. An agent that can read broadly to do its job well doesn't need write access to match. Splitting these into separate tools, with separate authorization rules, means a manipulation that successfully gets the agent to over-read is a lower-severity incident than one that gets it to over-write, and it keeps the two failure modes from compounding into each other.
Require step-up approval for anything consequential
For actions that are costly, irreversible, or sensitive, add a step that isn't just another automated check but a genuine pause: human approval, a secondary confirmation, or a cooling-off period before the action executes. This isn't about distrusting the agent specifically. It's about recognizing that some actions deserve a deliberate checkpoint regardless of how the decision was made, human or model.
Default to deny for anything new
When a new tool or capability gets added to an agent, the safer default is denying access until someone explicitly grants it, rather than allowing access until someone notices it should have been restricted. Default-allow configurations are common because they're convenient during development, nothing blocks testing, nothing needs configuring up front, but that same convenience is exactly what lets an overly broad permission slip into production unnoticed. Default-deny costs a small amount of setup friction for every new capability and buys a meaningful reduction in the odds that unauthorized access exists simply because nobody got around to restricting it yet.
Where TELEON fits
TELEON enforces authorization at the tool-call boundary through a gateway positioned between the agent and the tools or model providers it calls, applying policy independently of the agent's own reasoning and regardless of which framework built the agent. That includes recording the identity, the requested action, the policy decision, and the outcome, which gives teams both a real-time enforcement point and the audit trail needed to review whether the authorization model is actually holding up in production.
Deciding what the policy should actually allow, which fields a tool can touch, which actions need step-up approval, is a design decision specific to each application's own risk tolerance and workflow.
A short checklist
- Enforce authorization at the tool call itself, never rely on prompt instructions alone.
- Scope every tool to the narrowest set of parameters and actions it actually needs.
- Bind tool calls to specific, real identities rather than one shared credential.
- Separate read and write operations into distinct tools with distinct rules.
- Require step-up human approval for costly, irreversible, or sensitive actions.
- Use an authorization source independent of the agent's own generated reasoning.
- Log every authorization decision, approved and denied, for later review.
- Re-test authorization boundaries whenever a new tool or permission is added.
Unauthorized agent actions are rarely the result of some exotic new attack technique. They're usually the predictable result of authorization logic that lived inside the model's instructions instead of outside them. Moving that enforcement to an independent layer, and keeping tool scope narrow, closes most of the gap before anything more sophisticated even needs to come into play, and it does so without requiring anyone to predict every manipulation technique an attacker might eventually try.