The Agent Doesn’t Need More Context. It Needs Less Authority.
The team diagnosed a context problem. They connected order history, CRM notes, the policy library, and a payment tool. The agent’s answers improved almost immediately.
Three weeks later, it found an outdated policy, approved a refund, retried after a timeout, and submitted the payment twice.
The model had more context than ever. The system had also given it far more authority than the task required.
That distinction is becoming one of the most important ideas in AI engineering.
Look at the Permission Diff
The prototype began with a narrow role:
READ: current support ticket and approved FAQ
WRITE: draft response
MONEY: no accessBy the time it reached production, the role looked different:
READ: CRM, order history and policy archive
WRITE: customer records and ticket status
MONEY: refunds up to $500No single permission appeared unreasonable when it was added.
Together, however, they changed the cost of one incorrect decision. The agent was no longer helping an employee make a choice. It could now turn its own interpretation into a real business action.
Context and Authority Solve Different Problems
Context helps an agent understand a situation.
Authority determines what the agent can change after reaching a conclusion.
Connecting another document, database, or API may improve an answer. It can also introduce conflicting policies, irrelevant records, malicious instructions, or data the customer was never authorized to access.
A well-informed mistake with write access is still a dangerous mistake.
OWASP describes this risk as Excessive Agency. Its causes include excessive functionality, excessive permissions, and excessive autonomy. The recommendation is not simply to write a stronger prompt. It is to reduce available tools, narrow their functions, limit permissions, and enforce authorization outside the model.
Give Every Agent a Capability Budget
Instead of asking, “What can this agent do?” define the smallest capability required for the current task.
Get Ravi Mansuriya’s stories in your inbox
Join Medium for free to get updates from this writer.
A useful capability budget has four limits:
- Data: Which exact records may it read?
- Action: May it recommend, draft, update, or execute?
- Value: What financial or operational limit applies?
- Time: When does the permission expire?
The refund agent might receive access to one order rather than the entire customer database. It could propose a refund but not issue it. A payment credential could be created only after approval and expire when the transaction ends.
This design reduces the blast radius without making the model less intelligent.
Approval Should Follow Consequence
Requiring approval for every tool call makes an agent frustrating. Allowing every action automatically makes it unsafe.
The boundary should depend on consequence and reversibility.
Reading an approved document may proceed automatically. Drafting a response may need no interruption. Sending that response, changing an account, cancelling a service, or moving money should face progressively stronger checks.
OpenAI’s guidance on guardrails and human review recommends pausing before side effects such as cancellations, edits, shell commands, and sensitive tool actions.
The approval decision should happen in application code or an independent policy layer, not inside the same model deciding what action it wants to take.
Agent Identity Is Becoming Infrastructure
On October 27, 2026, NIST published new design tenets for agent identity management.
The guidance proposes unique agent identities, zero standing privileges, short-lived authorization, revocable access, and architectural separation between reasoning and permission decisions.
That last point matters.
The model may decide what it would like to do. A separate system should decide whether it is allowed to do it.
Test What the Agent Refuses to Do
Most agent evaluations reward successful task completion. That leaves an important behavior unmeasured: stopping safely.
Give the agent conflicting policies, revoked credentials, repeated timeouts, cross-account requests, and instructions that exceed its approval limit.
Then measure whether it asks, pauses, denies, or escalates.
For teams planning to hire AI engineers, this is a more revealing evaluation than another prompt-writing exercise. At Spaculus Software, the stronger design question is not only whether an agent can complete a workflow, but whether the surrounding system can prevent it from completing the wrong one.
The best agent is not the one that can see everything and do anything.
It is the one that has exactly enough authority for the task in front of it.
