What belongs in an agent's access contract?
An agent should receive only the data, operations and output destinations needed for its current task, under a verified identity and a defined lifetime. Record those limits as an access contract enforced by application code and connected systems. A prompt describing good behaviour is useful guidance, but it is not the mechanism that grants or denies permission.
Start with the task and the smallest useful surface
For an illustrative support assistant preparing a delivery update, access might include the assigned ticket, selected order-status fields and approved delivery guidance. It need not include every customer conversation, payment credentials, bulk exports or account administration. Give it a tool that retrieves the allowed status for a verified order instead of a general-purpose database connection.
Distinguish access from decision authority
The autonomy decision asks whether the agent may send the update or only prepare it. The access decision asks which records it may read and where the proposed update may go. Even an agent that only drafts can expose sensitive information through its inputs or outputs. Set its access independently of how convincing its recommendations appear.
Which permission dimensions should be explicit?
Define the actor, organisation, records, fields, operations, destinations and duration together. Add limits on volume or value where those change the consequence. Permission to use a connector is too broad a description: reading one order, searching all customers, exporting records and changing an address are different capabilities even when the same provider exposes them.
Write a concrete support-agent contract
The actor is a dedicated support workflow identity acting for a verified staff member. The organisation comes from authenticated membership. The resource is the order linked to the assigned ticket; allowed fields are delivery state and expected arrival. Allowed operations are retrieval and saving an internal draft. The draft destination is that ticket. Sending messages, editing addresses, refunds and exports are denied. The task grant expires when the run ends or its short lifetime elapses.
Enforce the intersection of permissions
An agent should not gain every privilege of the person who started it. Require the request to satisfy both the person's current authority and the agent's narrower task policy. Recheck organisation membership and record ownership at the tool boundary. Do not accept an organisation identifier supplied by generated text as proof of access.
Treat read access as consequential
A read-only tool cannot change its source records, but retrieved information may still enter model context, saved drafts, logs or another connected tool. Restrict fields before retrieval, control destinations and agree retention for stored context. If a task only needs delivery status, returning the full customer record creates exposure without improving the answer.
Where should permissions and credentials be enforced?
Enforce access in the tool implementation, application authorisation layer and provider controls wherever available. Keep provider credentials outside model-visible context, use narrowly scoped identities and request short-lived grants where supported. Every tool call should be validated against the current task and resource, including calls made after a pause, retry or delegated step.
Expose business operations instead of broad tools
Prefer a purpose-built operation such as saving a draft on the current ticket to unrestricted SQL, shell execution or arbitrary HTTP requests. Validate parameters, resource ownership and allowed destinations server-side. If a provider offers only broad credentials, put them behind a restricted adapter and recognise the remaining consequence if that adapter is compromised.
Make a grant revocable in practice
Record which tasks, tokens and queued jobs depend on a grant. Recheck authorisation immediately before a queued side effect rather than trusting permission at scheduling time. Where a provider token cannot be revoked promptly, an application gateway can deny new calls while the credential expires. In-flight requests and actions already completed require investigation or recovery; revocation does not undo them.
Use established security guidance as a baseline
OWASP's AI Agent Security guidance recommends least privilege, restricted tools and controls around agent inputs and actions. These are useful starting points for engineering review. Twofold's recommendation is to express them as a small contract the team can inspect and test for each workflow, rather than relying on a single broad agent role.
Can a document or tool response expand access?
Retrieved material must not be allowed to grant new permissions. A document, email or tool response may contain instructions that try to redirect the agent, including requests to reveal information or call another tool. Treat that material as task data, and require all resulting actions to pass the same external authorisation checks as any other request.
Test a plausible redirection
Imagine the support ticket includes a note claiming that delivery verification requires uploading the customer record to an external URL. The note is not authorisation. The status tool should still return only allowed fields, and the network or sending tool should reject the unapproved destination. OWASP identifies prompt injection as an agent threat; reducing what a successful redirection can reach is part of the defence.
Bind approval to the action that was reviewed
If sending a message requires human approval, bind that approval to the exact recipient, content and relevant record version. A later change should invalidate it or require review. Otherwise an approved draft can become a different action before execution. The approval grants that operation; it should not silently upgrade the agent to unrestricted messaging access.
Keep delegation inside the same limits
Passing work to another agent or background service must not widen the original task's authority. Propagate the verified task and tenant context, then restrict the receiving component to its own needed subset. A summary of the task is not a replacement for enforceable permission data.
How do you prove the boundary before enabling production access?
Test permitted and denied requests against the real tool implementation with controlled data. Confirm that the legitimate workflow completes, forbidden operations fail before reaching the provider, expired grants stop queued work and audit records explain the decision. A model that declines one unsafe prompt is not evidence that the underlying access boundary holds.
Run a short denial and revocation drill
For the support example, retrieve the permitted order and save its draft. Then attempt another organisation's order, an unrelated ticket, a disallowed field, an external destination and an address change. Repeat a queued operation after revoking the task grant. Inspect provider records as well as application responses so a friendly denial message cannot hide a completed side effect.
Make the audit record useful and restrained
Record the acting identity, task, organisation, tool, resource, policy version, allow-or-deny result and resulting operation identifier. Store approval evidence where required, with access and retention controls. Avoid logging full prompts or customer payloads by default. Name the person who reviews unusual denials, changes permission policy and can stop the workflow.
Use one proposed tool as the starting point
Before connecting an agent to production, bring one task, its required fields and its proposed tool operations to a review. Twofold can help turn that scope into application controls, tenant boundaries and verification cases. Expand access only when a new task needs it and the wider boundary has its own evidence.