Permission-Aware Enterprise Agents: Whose Authority Applies?

Your agent can have permission to share a folder while the person asking it cannot.

That's easy to miss when the connection uses a service account with access across several projects. The request looks reasonable, the tool runs successfully, and the wrong person receives access to the right files.

Permission-aware enterprise agents need to establish whose authority applies at each step. The requesting user, connected application account, and business approver can be different people or identities. A working connection doesn't settle the relationship between them.

Consider a hypothetical project coordinator asking an agent to give an external reviewer seven days of read access to a project folder. The request sits in a service desk, the reviewer has a directory identity, and a document portal holds the folder.

The organisation's policy requires the folder owner to approve external access. Your workflow needs to carry that decision through execution and eventually remove the access it created.

Start with the person asking and the account acting

Before choosing a tool, write down the requesting identity and the identity each application will see. Get these from authenticated application context and trusted connection configuration. A user identifier supplied in a prompt isn't evidence that the speaker controls that account.

For the folder request, establish whether the coordinator may request access for this project. Resolve the reviewer to the intended directory identity and the folder to its stable application identifier. Two matching display names aren't enough.

Then inspect the document connection. Does it act as the coordinator, a dedicated automation account, or an application with its own permissions?

In Microsoft Graph, delegated permissions operate on behalf of a signed-in user, bounded by both the app's granted permissions and the user's access. Application permissions operate without a signed-in user. The exact permission and resource configuration determine what the application can reach. Microsoft Graph permissions overview

Other applications have their own models. Check the connection you're deploying rather than assuming that every operation inherits the requesting person's permissions.

A background service may legitimately need its own identity. If that identity covers several projects, the executing service must still enforce which projects this caller can use. The broader account must not become a way for the coordinator to grant access elsewhere.

Separate the decisions hidden inside “allowed”

The folder workflow contains several decisions. Keeping them explicit makes it easier to find the missing control.

These decisions can be enforced by existing identity systems, the application, a tool service, and the surrounding workflow. Assign an owner to each check so one component doesn't assume another has done it.

Showing the agent a smaller tool list helps guide its choices. The execution service must also reject an unauthorised call if the model requests it anyway. OWASP recommends denying access by default and validating permissions on every request. OWASP authorization guidance

For this case, expose a narrow operation for an approved folder grant. Keep the permitted role and folder scope in enforced policy. Don't let a request for read access turn into an editor grant because the model supplies a different argument.

The internal application integration guide covers building the underlying operation. Here, the job is to establish who may invoke it and under which conditions.

Keep credentials at the correct boundary

An agent client reaching a tool server and that server reaching the document portal are separate connections.

The current MCP authorization security specification requires servers to validate that incoming tokens were issued for them. It forbids passing the client's token through to an upstream API; that upstream connection uses its own appropriately issued token. MCP authorization security considerations

Apply the same care when reviewing the whole workflow. Identify where credentials are held, which service selects the connection, and how a caller is associated with the permitted account. Keep that selection outside model-generated arguments.

For the project request, the agent should not be able to choose an administrator connection after a restricted account is denied. A denial needs a resolution under the organisation's access process.

To prepare the approval request, establish the folder owner's identity, the intended recipient, and the existing permissions. It doesn't necessarily require reading the documents themselves. Return the evidence the folder owner needs without pulling unrelated project material into the conversation.

Make the approval describe the access being granted

An approval button labelled “Continue” gives the folder owner too little to assess.

Show the resolved reviewer identity, exact folder, read-only role, start and end time, and requesting coordinator. Explain whether the change affects child folders or files, based on the portal's actual permission behaviour.

OWASP's transaction authorization guidance recommends showing the significant details of an operation and protecting the approved data against later modification. Applying that principle here means binding approval to the specific access proposal. OWASP transaction authorization guidance

The organisation decides who can approve and whether delegation is allowed. A ticket saying “the owner approved this” should lead to the authoritative approval record, not replace it.

If the reviewer changes, the role expands, or the folder is substituted, obtain the required approval for that changed proposal. Store the decision outside the chat so execution can check what was actually approved.

Treat instructions found inside a document or ticket as content to evaluate. They cannot appoint a new approver or extend the requested access period.

Recheck the grant when the waiting ends

Suppose the owner approves on Monday, but the run resumes on Wednesday. The reviewer may have been disabled in the directory, the project may have closed, or the approval may have been withdrawn.

Before the write, check the facts the organisation's policy makes relevant. Confirm the intended identity, folder, approval, and remaining access period. If that period has ended, stop; don't silently restart the seven-day clock because execution was delayed.

Use a target application's conditional update or equivalent concurrency control where it supports the operation. A separate read followed by a write can leave a gap in which the relevant state changes. Where the application can't protect a consequential condition adequately, keep that case with a person or redesign the operation.

After execution, inspect the resulting permission. Confirm its recipient, resource, and role. If the portal doesn't support automatic expiry for this grant, the workflow needs a scheduled removal with an owner and a way to detect failure.

An expiry date written in the service ticket doesn't establish that access will end. Until the removal path is proved, report that limitation in the proposed workflow.

Revocation has more than one job

Disconnecting the agent can prevent future work while leaving the reviewer's folder access in place. Removing the folder grant can end that access while leaving the automation account able to create another one.

Decide which result is required when someone cancels the request, withdraws approval, or disables the connection. For this example, cancellation before execution should stop queued work. Cancellation after execution may also require removing the resulting permission under the agreed policy.

OAuth token revocation has implementation details worth testing. RFC 7009 describes possible propagation delay and differences in how revocation affects related tokens. Revoking a refresh token doesn't universally establish that every outstanding access token has stopped working. OAuth token revocation specification

Test the connection you use, including suspended runs and queued retries. A paused run should stop if its connection authority or business approval no longer applies. Resume only after the missing requirement is satisfied under the organisation's process.

For the reviewer, verify the resulting access through the portal's supported permission checks. If another group or inherited grant also gives them access, removing this workflow's grant may not remove all access. Escalate that finding to the owner without deleting unrelated permissions automatically.

Removing access also doesn't retrieve files the reviewer has already downloaded. Define the result the workflow can establish and report that result accurately.

Leave evidence that explains the decision

A tool execution log may show that a service account changed a permission. Your operator also needs to know why.

Keep a case record joining the requester, resolved recipient and folder, approval reference, execution identity, attempted change, and confirmed result. Include the intended expiry and the result of removal. When a check rejects the request, preserve enough context to explain the decision without exposing material the requester can't access.

Keep secrets out of that record. OWASP's logging guidance identifies access tokens and other sensitive values that should generally be removed, masked, or otherwise protected before logging. Decide who can inspect the evidence and how long it is needed. OWASP logging guidance

In a controlled test environment, run a legitimate request alongside another project's folder, a substituted reviewer, withdrawn approval, a disabled connection, and failed expiry removal. Ask the operator to explain each result from the saved evidence.

Where Monarch fits

Monarch is the orchestration layer between agents and enterprise applications. Its Product Graph discovers available operations and captures verified application behaviour within the connected account's scope.

For this example, evaluate the directory lookup, document permission operation, and service-case updates under the accounts your team intends to use. Your organisation defines who may request access, who approves it, and when it must end. Verify those controls and the removal process in the proposed deployment.

If your access-management process already grants and removes access correctly, use it. For a Monarch evaluation, focus on the gaps between the directory, document portal, and service desk, and bring evidence of the controls into the security review.

Bring one permission-sensitive workflow to a Monarch pilot discussion, including a case that must be rejected and access that must later be removed. Prove those outcomes alongside the successful request.