The short answer#
Give an AI agent only the records and actions needed for its current business task, with permissions enforced outside the model. Separate reading, drafting and committing changes. Before expanding access, require a permission register, tests that forbidden actions fail, and a named owner who can revoke access.
Start with the business task, then grant access#
An assistant that answers shipment-status questions needs access to shipment facts. That task alone gives no reason to let it change a booking, issue a refund or browse every customer's commercial records.
This is least privilege applied to an agent: each permission must have a reason tied to the work you are funding. Begin with a sentence such as, “Help an operations colleague prepare a status update for a shipment they are authorised to view.” Ask the team to justify each additional capability against that sentence.
An instruction such as “never change bookings” describes intended behaviour. The booking system's permissions determine whether a change can actually happen. OWASP's guidance on excessive agency recommends restricting tools and their downstream permissions, with authorisation enforced independently of the model.
The business consequence is easier to assess when access is explicit: a mistaken draft needs correction; an unauthorised booking change may require operational recovery and a customer explanation.
Approve a permission register for one workflow#
An illustrative register for a shipment-status assistant:
| Capability | Proposed boundary | Evidence to ask for |
|---|---|---|
| Read shipment status | Only shipments the requesting colleague may view; only fields needed for the answer | A request for another customer's shipment is denied |
| Draft an update | Save a proposed message in that colleague's private review area | Creating a draft causes no external send |
| Send an update | Outside the first pilot; if added later, require an authorised reviewer and an approved recipient | A changed recipient requires a fresh decision |
| Change bookings or rates | No access for this task | Attempts fail at the business API |
| Run arbitrary commands or queries | No access for this task | The agent cannot reach a general command or query tool |
For every permitted row, name the identity used to execute it, the records and fields it can reach, the action, the destination and the access duration. Add the owner, the enforcing system and the test that demonstrates the boundary.
A connector labelled “shipment system” says little about its effective access. It might use the colleague's identity, a restricted service identity, or an administrator account shared across workflows. Ask which it uses and how the colleague's own restrictions remain effective. Signing in proves identity; each requested operation still needs an access check.
For background processing with no colleague present, define a dedicated business scope. Do not silently inherit the access of whoever configured the connector. Where supported, use temporary credentials and review unused permissions; AWS's IAM guidance provides one concrete implementation of those principles.
Separate the proposal from the right to execute it#
An unauthorised change can leave your operations team repairing records and explaining a mistake to a customer. The executor is the part of your application that actually carries out an action. It must check each proposed request against trusted identity and policy data before the request reaches the business system, including when the model says it is allowed.
In the shipment example, a tool to fetch an authorised shipment's status has a narrower purpose than a tool that can execute any database query. Keep the underlying connection restricted too: removing a visible tool is insufficient if another route offers the same power.
Where a later phase includes approval, the executor must verify approval for the actual action and target. A model-generated statement that a reviewer agreed is insufficient. Detailed approval design is a separate decision; here, the essential distinction is that permission to draft does not include permission to commit.
If one customer's shipment or commercial data appears in another customer's answer, it can put your confidentiality commitments at risk and damage trust. A system that cannot modify its source can still disclose what it reads through a response, an external request or shared conversation history. OWASP's AI agent security guidance covers these disclosure paths and isolation between users and sessions. For the pilot, restrict the available data and outbound destinations, and keep one customer's context from appearing in another customer's answer.
Keep development access away from live operations#
A recoverable mistake can still interrupt work and consume recovery time. In its 29 July 2025 account, Replit acknowledged that its agent had deleted data from an app's database while the app was being built. It said the database was fully restored through rollback, and explained that development changes could affect the production application under the earlier arrangement.
Replit had announced separate development and production databases on 21 July 2025. In its subsequent account, Replit described this separation as preventing the agent from changing the production database during development.
The architectural lesson we draw is to remove the development agent's route to modify live data, including credentials and indirect tools that could restore that route. Such a boundary would block a development write to production through the protected path. A separate database is useful only if the development environment cannot obtain permission to change the live one.
Keep recovery capability as well. Access control limits what can happen; a tested restore addresses damage when another control fails. Neither replaces the other.
Make denial evidence part of acceptance#
A successful demonstration shows that the agent can complete permitted work. Ask for evidence that the application also refuses work outside its scope. OWASP's authorisation guidance recommends default denial, checks on every request and tests against the permissions defined during design.
For this illustrative pilot, set the following acceptance criteria before testing:
- An authorised colleague receives the permitted status fields for their shipment.
- Substituting another customer's shipment identifier returns no protected data.
- Asking for a booking change fails through every exposed route, including any general connector.
- A draft remains private and unsent, even if an incoming document instructs the agent to send it elsewhere.
- Revoking access prevents subsequent work; the team demonstrates what happens to queued actions and active sessions.
- If the permission check cannot complete, the requested action is refused and an operator can see why.
Use the real integration path in a controlled test environment. An answer saying “I cannot do that” is useful behaviour, but the stronger evidence is that the executor refused the attempted operation and the business system remained unchanged.
Retain protected records of the caller, target, requested action, permission decision and execution outcome. Avoid filling those records with customer content or credentials. Ask the team to show the system's evidence alongside the agent's account of what happened.
What this means for you#
Fund the smallest access scope that can demonstrate business value. For the status assistant, measure whether colleagues produce accurate updates faster after checking and correction. Add sending only if the remaining manual step is a material constraint and the controls pass acceptance.
Narrower access has a trade-off: more exceptions may reach a colleague. Record those exceptions and their handling time. Expand access when the value of resolving a specific exception justifies the added exposure and operating effort.
When buying a platform, ask the vendor to demonstrate the permission register against your intended connectors. When building, budget for those controls and tests alongside the agent itself. If a legacy system offers only broad credentials, consider an integration layer exposing a few permitted operations, or retain a manual hand-off. A consulting engagement can help assess that integration choice; ownership of the access decision stays with your organisation.
Questions to ask before you approve agent access#
- Which business task justifies every permission, and who owns that decision?
- Can you show the effective identity, record scope and allowed operations at the connected system?
- Which attempted actions were refused, and what evidence shows nothing changed or leaked?
- Can a general tool, another agent or a queued action bypass the same restriction?
- Who can revoke access, and how quickly does that take effect for active work?
Bring one proposed workflow and its permission register to the conversation. Discuss your project.