AI Agent Permissions: Whose Access Should the Agent Use?
Start with the short answer ↓
A connected agent may reach more than the employee asking for help. Map requester identity, application access and record scope before allowing the agent to act.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Name the person, application and record behind each action
A coordinator asks an AI agent to move a service visit. The agent is connected to the scheduling system through an integration account that can edit every branch. Should it inherit that entire reach when responding to this one employee? The useful starting question is whose authority the proposed change represents, before deciding how much work the agent can automate.
Keep three identities visible in the design: the person asking, the application making the technical request and the customer or business unit affected. A model may propose a tool call, but that proposal should not decide which identity the application uses. Being able to connect to a system does not establish permission for every action available through that connection.
This guide uses an invented scheduling exercise to help scope AI agent permissions. It is not a description of a customer deployment or a claim that AgenticShip already provides a particular identity platform. The aim is a small, testable authority chain that a business owner can review with the delivery team.
Choose explicitly between acting for a user and running a background process
Microsoft's identity documentation distinguishes delegated access on behalf of a signed-in user from app-only access using the application's own identity. In its delegated model, both the application and user need authorization; app-only permissions do not depend on a signed-in user. These are Microsoft-specific concepts, not proof that every CRM or agent connector implements the same restrictions.
For an employee assistant, ask whether the integration can preserve the requesting employee’s permitted scope. For a scheduled background process, name the business responsibility that authorizes it to run without that employee. The correct choice depends on the actual provider and workflow. Neither an individual login nor a dedicated integration identity removes the need to examine the reachable records and actions.
A common design gap is a narrow employee interface backed by a broadly privileged connector. If the provider offers only coarse access, document that limit and decide which additional controls the surrounding application must enforce. If the proposed scope cannot be enforced and tested, keep that operation outside the first release rather than describing a prompt restriction as a permission boundary.
Read Microsoft’s delegated and app-only access distinction →
Follow one proposed visit change through the authority chain
In our fictional example, Maya coordinates the North branch. Job J-204 belongs to North; job J-805 belongs to South. Her assistant may prepare a new time for an assigned North job. Changing another branch’s work is outside her current responsibility. The connector can technically reach both jobs, so testing only a successful North request would miss the important boundary.
The application should obtain Maya’s current identity and branch from its trusted session or identity service, resolve the actual job and check the permitted operation. A branch name written in the chat is a proposed input, not authority. Asking the agent to operate on J-805 must not let it borrow the connector’s broader reach or silently switch to a manager identity.
Suppose the new visit time requires a supervisor decision under the business’s agreed rules. That decision belongs to the named job and proposed change. It should not become general permission for Maya to edit South or for the assistant to choose a different customer. A changed record, recipient or action needs the corresponding decision to be checked again.
Use an identity-to-action worksheet in discovery
Complete this worksheet for one real workflow before connecting a broad tool set. The proposed boundaries below belong to the fictional scheduling exercise. They are not universal role definitions or a claim that an API supports each restriction. Ask the delivery team to identify the actual enforcement point and an observable test for every row.
| Proposed operation | Authority to establish | Boundary to demonstrate |
|---|---|---|
| Read job J-204 to prepare a suggestion | Current requester, North membership and access to that job | Only the permitted job details reach the assistant |
| Move the visit after the required review | Permitted requester, exact job and applicable supervisor decision | Approval for J-204 cannot authorize J-805 |
| Process a scheduled North reminder queue | Named background-process owner and defined service identity | No employee session is silently impersonated; South remains outside scope |
| Resume an earlier proposed change | Current authority and the still-applicable reviewed action | A saved plan does not bypass a later role or assignment change |
| Investigate a denied attempt | Authorized support role and restricted diagnostic access | An error explanation does not disclose the other branch’s job details |
Recheck authority when a prepared action is executed
OWASP recommends least privilege, denial by default and permission validation on every request. Apply those principles to the application path that reads or changes a record, not only to the chat interface. An agent’s confident statement that it has permission is not an authorization result.
Now remove Maya from North while her proposed visit change is waiting. Agree what the application must do when that work resumes: stop the employee-initiated action, preserve its status and route it to a currently authorized owner. A legitimate independent background process needs its own defined authority; it must not casually reuse Maya’s old request as a new grant.
Do not promise that disabling a login instantly invalidates every token, cached decision or pending task. Ask how the chosen provider and application handle those cases, what delay may remain and what can be paused during a change. Record the demonstrated behavior. Reauthorization timing is an implementation requirement, not a benefit established by calling the assistant secure.
Keep the authority visible without exposing credentials
For the exercise, the operator should be able to explain which requester started the work, which application identity executed it, which job was affected and which rule allowed or denied the operation. Include the applicable review reference and final outcome where needed. A single agent name in a log cannot answer all of those questions.
Keep credentials out of prompts, customer messages and ordinary diagnostic output. An identity reference is useful evidence; the secret that authenticates it is not. Give support staff an explanation of a denied action without exposing another branch’s record contents. Decide separately who can inspect detailed evidence and how long the business needs to retain it.
When the workflow crosses a second system, repeat the mapping. Permission to read a scheduling job does not automatically establish authority to send a message from a shared mailbox. Track the real technical identity and business decision at each relevant step rather than assuming that the first successful connection authorizes the whole chain.
Define the evidence an operational audit trail should retain
Ask for a demonstration that includes a changed identity
Test in an isolated environment using invented people, branches and jobs, with real messages and operational writes disabled. Run the ordinary North request, the South request, a job identifier substituted after review and a request resumed after Maya loses her branch responsibility. Check the actual application and tool outcome, not only the wording of the assistant’s answer.
Include the background reminder process as a separate case. Verify that its documented business scope still works without borrowing a departing employee’s identity. Also test a missing identity or unavailable permission service: the expected fallback should preserve the request for an authorized person, not quietly run through a broader connector.
Agree which results block release and who owns corrections. An unauthorized South read, a changed job executed under an old decision or an unexplained identity substitution should not be counted as a successful demonstration. Ordinary permitted work must still succeed. This exercise tests the stated boundary; it does not certify the entire system or every provider behavior.
For a first implementation, bring one employee request, one background task and the real access limits of the connected system. A useful outcome is an agreed identity-to-action worksheet and repeatable acceptance cases. Expand the tool set when the team can explain whose authority each new operation uses and demonstrate where that authority ends.
Add identity changes to the agent acceptance tests
Scope AI agent implementation around a defined business workflow
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.