Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.
An agent preparing a weekly operations briefing may need to read shipment records. It does not automatically need to change delivery addresses, export every customer or delete old orders. Least privilege begins by separating the task from the full capabilities of the connected application.
This is familiar security practice with a new source of uncertainty: a model may choose among available tools based on language and intermediate results. The application should therefore enforce a narrow boundary even when the assistant is confused, manipulated or simply wrong. A prompt describing good behavior is not that boundary.
Build a task-to-permission matrix
Imagine a hypothetical logistics assistant with three responsibilities: answer shipment-status questions, prepare exception summaries and draft customer updates. List the data and operations each responsibility requires. Status answers may need read access to assigned shipments. Summaries may need a limited date range. Drafts may need a place to save text but no permission to send it.
Now compare that matrix with the credentials and tools actually exposed. A connector may inherit a broad account role because it was easy to configure during the pilot. Remove capabilities that the approved tasks do not require. The absence of a dangerous tool can be a stronger safeguard than an instruction not to call it.
OWASP’s excessive-agency guidance distinguishes excessive functionality, permissions and autonomy. That is a useful review lens: inspect what the tool can do, what its identity can access and when the agent may act without review. These are related but separate decisions.
Separate read, draft and commit
A user may authorize an investigation without authorizing a change. Model the progression explicitly. Reading a shipment record, drafting a customer message and sending the message should have distinguishable capabilities and audit events. Do not hide all three behind a vague “resolve issue” action.
A draft can still contain sensitive information, so read-only does not mean risk-free. A briefing that collects restricted records into one document may create a new disclosure surface. Limit source access and control where the resulting artifact is stored and who can open it.
For consequential changes, require the application to verify the necessary authority at execution time. An approval can be part of that check, but it should not replace resource-level permission. A reviewer entitled to approve one account’s action should not thereby gain authority over every account.
Prefer scoped identities over shared superusers
Identify which user or service identity reaches the business system. If every task uses one highly privileged account, the application has to recreate all user boundaries perfectly. That increases the consequences of a mapping or policy error. Use the narrowest practical identity and scopes for the intended workflow.
Document how credentials are issued, stored, rotated and revoked. Keep them out of prompts and unnecessary logs. If an agent delegates work, do not assume that delegation should copy the parent’s full authority. A research subtask may need fewer tools and less data than the coordinating process.
For MCP integrations, the official security guidance discusses scope minimization and credential-related risks. Apply it to the actual server configuration. Protocol support does not by itself determine which downstream records a credential can reach.
Check permissions when the action happens
A task may begin while a user has access and continue after that access is revoked. An approval may wait overnight while a role changes. Recheck the relevant authority at execution rather than relying solely on the state captured when the conversation started.
This matters for cached data too. Decide whether previously retrieved content may still be shown after access changes, and how the product handles saved artifacts. The right policy depends on the system and data, but it should be explicit rather than an accidental consequence of a cache.
A denied action should produce a clear, safe outcome. The agent can explain that the current scope does not permit the change and identify the appropriate approval route. It should not seek a different tool, identity or export path merely to accomplish the same forbidden result.
Use approval for the right boundary
Some actions warrant a human decision because they create a commitment or an irreversible effect. The OpenAI Agents SDK approval documentation describes mechanisms for gated execution. The business still needs to define which actions require review and who can provide it.
Avoid broad approval language such as “allow access to the account” when the immediate proposal is a specific message or field change. A reviewer should understand the action being permitted. If broader ongoing authority is necessary, grant it separately with a clear scope and revocation path.
Prove the denied paths work
- Ask a read-only agent to modify a record and verify that the backend rejects it.
- Use two users with different account access and compare what each can retrieve.
- Revoke a credential during a running task and inspect subsequent behavior.
- Attempt an action through a different exposed tool after the intended tool denies it.
- Check that delegated tasks receive only their required authority.
- Inspect generated artifacts and logs for information outside the approved scope.
Run these tests in a controlled environment with synthetic or approved data. The important result is not whether the model verbally refuses. It is whether the prohibited action remains impossible through the available execution paths. Record both the application response and the destination state.
Review permissions as the workflow changes
A new tool, a new data source or a broader business objective should trigger a permission review. Remove credentials and capabilities left over from experiments. Keep the task matrix current so operators can explain why each permission exists.
Least privilege is a design habit rather than a one-time checkbox. It lets an agent be useful within a clear operating envelope and limits the damage when something goes wrong. The practical question is simple: what is the smallest authority this task needs, and can the application enforce that boundary even when the model does not?
Sources and further reading
OWASP: Excessive Agency. 2025 distinctions among excessive functionality, permissions and autonomy; checked October 2026.
MCP: Security best practices. Versioned scope and credential guidance; checked October 2026.
OpenAI Agents SDK: Human-in-the-loop. Approval-gated execution mechanisms; checked October 2026.
Leave a Reply