AI Agent Permissions and OAuth Grants: An Enterprise Security Guide

‍

What an OAuth grant actually authorizes

OAuth lets an application obtain limited access to a protected resource without receiving the user's password. In the OAuth 2.0 model, an authorization grant represents permission from a resource owner. The client exchanges that grant for an access token, which it presents when requesting a protected resource. The token represents a particular scope and duration of access. A refresh token, when issued, can allow the client to obtain new access tokens without repeating the original authorization flow.

In everyday enterprise use, the phrase OAuth grant often refers to the durable relationship among:

• the client application
• the authorizing user or administrator
• the resource or API
• the approved scopes or roles
• the resulting access and refresh tokens
• the policies and conditions applied by the authorization server

These elements should not be treated as interchangeable. A scope describes a category of access the client may request. A grant records authorization. An access token is the credential used at runtime. A refresh token may extend the practical lifetime of the relationship by obtaining new access tokens.

The most important distinction for security teams is between delegated and application-level access.

With delegated access, the application acts on behalf of a user. What it can do usually depends on both the granted scope and the user's own permissions. With application-level access, the application acts as itself, without a signed-in user, and may have broad access across a tenant or environment. Provider terminology differs, but the investigation question is the same: whose authority is the agent using, and what effective access results from it?

OAuth is also only one part of the inventory. The same agent may use a service account in one system, an API key in another, and a user-delegated OAuth grant in a third. Reviewing only the OAuth application can miss much of the agent's real reach.

For protocol details, see OAuth 2.0, RFC 6749 and the current OAuth 2.0 Security Best Current Practice, RFC 9700.

Why AI agents make delegated access harder to govern

Delegated access was already difficult to review when applications performed a narrow set of predictable functions. AI agents change the operating model in several ways. In Offroad's Identity Underground Annual Pulse 2026, only 5% of security teams said they were confident in their non-human identity inventory, and 45% reported that a meaningful share of that access is not reliably visible to the team responsible for it — a gap that widens as AI agents multiply the number of connections to track.

First, an agent may use the same permission across many different tasks. A mail permission might support drafting, searching, summarizing, sending, or deleting. The scope alone does not tell the team which of those actions are intended.

Second, people tend to optimize for completing the task. A user may approve access after seeing several permission prompts, without understanding how long the grant will remain active or how broadly it can be reused. The initial consent may be legitimate while the continuing access becomes excessive.

Third, agents can act across several systems as part of one workflow. A single task might read a support ticket, query a CRM record, inspect a document, update an issue tracker, and send a message. Each connection may appear reasonable in isolation while the combined path creates a much larger blast radius.

Fourth, volume changes the risk. An agent can perform more actions in a short period than a person typically would. A permission that was rarely dangerous in human use may have a different impact when it supports automated, repeated, or chained actions.

Finally, anomaly detection alone is not enough. Agent activity may be new, high-volume, or unusual by design. The useful question is not simply whether the behavior is different. It is whether the behavior makes sense for this agent, this task, this owner, and this moment in the business.

This is why AI-agent governance needs more than a token list or a one-time access review. It needs connected context.

A field lesson from repeated permission prompts

In a talk on runtime identity security, my co-founder Dan Bendler described asking an AI assistant to prepare personalized outreach emails. The assistant requested permission before each send. Dan initially selected “allow once,” but after repeating the approval several times, he selected “allow always” so he could finish the task.

The important point was not that the user ignored security. Dan was consciously thinking about security while using the agent. The problem was that a repeated runtime decision gradually became workflow friction. The durable permission solved the immediate usability problem, but it also changed the access relationship after the original task.

That experience suggests a practical governance principle: consent is not enough context. A security team should also be able to determine what task led to the approval, whether the access persisted beyond that task, which actions the agent performed afterward, and whether the continuing grant still matches the user's intent.

The inventory security teams actually need

A useful inventory must let an investigator move from the agent to every identity, credential, permission, resource, owner, and workflow connected to it.

At a minimum, record the following fields.

Agent

What is the agent called? Who created it? Where is it deployed? What is its approved purpose?

Ownership

Which person and business team are accountable for it? Is the owner still active and in the same role?

Identity

Does it act as a user, service account, service principal, application, workload identity, or several of these?

Authorization

Who or what granted access? Was consent given by a user or administrator? Was the approval tenant-wide?

Credentials

Which access tokens, refresh tokens, API keys, certificates, secrets, or other credentials support it? Where are they stored and rotated?

Permissions

Which scopes, roles, entitlements, and inherited permissions are assigned? Which are delegated and which are application-level?

Effective access

Which data, applications, APIs, and administrative actions can the agent actually reach, including through groups, roles, trust relationships, or connected applications?

Activity

Which permissions and resources has the agent used? When was the last successful use? What volume and action types are normal?

Dependencies

Which automations, business processes, users, or downstream systems rely on the connection?

Governance

Which policy approved the access? When was it last reviewed? What changes, exceptions, and remediation actions have occurred?This data rarely lives in one system. Identity providers show consent and application objects. SaaS platforms expose scopes and audit logs. Cloud providers show workload identities and roles. Source-control and automation platforms may hold additional tokens or secrets. Ticketing, HR, and collaboration systems often contain the missing owner, purpose, and approval context.

An access graph can connect the identity and authorization relationships. Activity and business context are still required to determine whether the access is being used appropriately. This distinction is explored in What Is an Identity Graph? A Practical Guide for Identity Security Teams. In Offroad's terminology, the Identity Graph is one component of the broader Identity Fabric, which connects access with activity, ownership, approvals, policies, and business context.

How to evaluate scope, ownership, activity, and blast radius

A high-risk scope deserves attention, but scope alone is not a verdict. Evaluate each connection across four dimensions.

1. Scope and effective permission

Start with what the grant says, then determine what it means in this environment.

• Is the access read-only, write-capable, destructive, administrative, or capable of granting more access?
• Does the permission apply to one resource, a selected set, or the entire tenant?
• Is the access delegated through a highly privileged user?
• Can groups, inherited roles, connected applications, or impersonation expand the practical reach?
• Does the agent need every approved scope for its current purpose?

The current OAuth security best practice recommends restricting token privileges to the minimum required and limiting tokens to their intended resource servers. Those controls reduce risk, but the enterprise must still verify how the provider implements scopes and how other authorization layers affect the final result.

2. Ownership and purpose

Every agent and connection should have an accountable owner and a documented business purpose. A creator is not always the current owner, and the person who clicked consent may not be the right person to approve ongoing use.

Check whether the owner is active, understands the workflow, can explain the requested access, and has authority to accept the risk. If nobody can do that, the connection is not governed, even if it appears in an inventory.

3. Runtime activity

Compare assigned access with observed use.

• Which scopes have produced successful actions?
• Which resources were accessed?
• What actions were performed, by which identity, and in response to which workflow?
• Is the volume, timing, or sequence consistent with the agent's approved purpose?
• Are high-impact permissions unused, newly used, or used outside the expected process?

No observed use does not automatically prove a permission is safe to remove. The permission may support an infrequent but critical process, or the available logs may be incomplete. Treat inactivity as an investigation signal, not as sufficient evidence by itself.

4. Blast radius and dependencies

Blast radius is the potential consequence if the credential is stolen, the agent is misdirected, the connected application is compromised, or the permission is misused.

Consider both direct and indirect impact. Could the agent read sensitive data, alter production, send messages as a trusted user, change access, retrieve secrets, modify source code, or trigger another privileged workflow? Could one connection be used to reach additional systems?

Then identify what might break if access changes. A grant can be excessive and still support a legitimate dependency. Safe remediation requires understanding both sides of that decision.

Worked example: Investigating a persistent mail grant

Consider an AI assistant approved to draft and send personalized event invitations. This is an illustrative workflow, not a customer incident.

The employee initially approves mail access while completing a specific outreach task. After several individual confirmations, the employee allows the assistant to retain access. Three months later, a security review finds the OAuth application with permission to read and send mail.

A scope-only review labels the grant high risk because it can access a sensitive mailbox and send messages as the user. That label is useful for prioritization, but it does not answer what to do next.

The investigator connects six pieces of evidence:

1. Purpose: The original event campaign has ended.
2. Owner: The consenting employee is active, but no team owns the continuing integration.
3. Authorization: The grant is user-delegated, and an associated refresh token can obtain new access tokens without a new prompt.
4. Activity: The send permission was used during the campaign. The read permission continued to be used afterward.
5. Reach: The agent can access the employee's mailbox, which contains customer conversations and password-reset messages.
6. Dependencies: No active automation or approved business process depends on the connection.

The evidence supports revocation, but the team still prepares the change. It records the grant and scopes, confirms that the campaign is complete, identifies how the employee could reconnect the assistant through a new approval if required, and defines two verification tests: the old connection must fail to access mail, and the employee's normal mailbox workflow must continue.

After revocation, the team checks the provider's effective state, tests the old connection, monitors for automatic reauthorization, and records the result. The issue is closed only after the access path is confirmed inactive.

This example shows why a useful investigation cannot stop at “the application has a risky scope.” The decision depends on purpose, ownership, runtime activity, exposed resources, dependencies, and a verified outcome.

Warning signs of a risky or abandoned grant

The following conditions should increase investigation priority:

• no accountable owner or business sponsor
• an owner who has left the company or changed roles
• no documented purpose, approval, or expected workflow
• tenant-wide or administrative access for a narrow use case
• write, delete, send, impersonate, or access-management permissions that are not clearly required
• a mismatch between requested scopes and observed activity
• long-lived or renewable access with no recent review
• secrets or tokens stored outside approved systems
• credentials that are not rotated or whose age cannot be established
• new activity after a long inactive period
• access from an unexpected identity, application instance, environment, or workflow
• sudden changes in volume, resource targets, or action sequence
• multiple agents sharing one credential
• a grant connected to a dormant, unverified, or unapproved application
• dependencies that nobody can explain
• failed or partial remediation that was never verified

Any one signal may have a legitimate explanation. Several connected signals are more meaningful than an isolated label such as “high-risk scope.”

The same principle applies to periodic certifications. Why Access Reviews Fail to Reduce Identity Risk explains why presenting a reviewer with an entitlement name, without use, ownership, purpose, or dependency context, often produces approval rather than a defensible decision.

A step-by-step investigation workflow

Step 1: Identify the real object under review

Determine whether the finding refers to an OAuth client, a user consent grant, an administrator consent grant, a service principal, a token, a service account, or the agent itself. Capture stable identifiers, not only display names.

Step 2: Establish ownership and intended purpose

Identify the current technical owner, business owner, approving authority, and users or teams that rely on the agent. Record the task the agent is supposed to perform and the environments in which it is allowed to operate.

Step 3: Reconstruct how access was granted

Find who authorized the connection, when it happened, whether the consent was user-specific or organization-wide, and whether later changes expanded the access. Confirm whether the grant still exists and whether active credentials can still be derived from it.

Step 4: Translate scopes into effective access

Map each scope or role to the actions and resources it enables. Include the permissions of the delegating user, inherited roles, group membership, application assignments, resource-specific controls, and any connected system that can extend the path.

Step 5: Review credential exposure and lifetime

Identify access tokens, refresh tokens, client secrets, certificates, API keys, and adjacent credentials. Check where they are stored, who can retrieve them, how they are rotated, whether they are sender-constrained where supported, and whether unused credentials expire.

Step 6: Analyze runtime activity

Build a timeline of successful and failed actions. Compare permission use, resources, volume, timing, and sequence with the intended workflow. Include application, API, cloud, identity, and security logs where available.

Step 7: Map blast radius and operational dependencies

Determine what the agent could do if compromised and what legitimate process could fail if access is removed. Follow indirect paths across roles, applications, APIs, data stores, and automation chains.

Step 8: Choose the smallest safe change

Options may include removing an unused scope, replacing a tenant-wide grant with narrower access, restricting resource access, changing the delegated identity, rotating a credential, shortening token lifetime, disabling the agent, or revoking the grant entirely. Prefer the action that reduces the identified risk while preserving the approved use case.

Step 9: Approve, execute, and verify

Use the approval required by policy. Record the intended change and expected effect before execution. Afterward, verify effective access and test the legitimate workflow. An API success response confirms that a request was accepted. It does not by itself prove that every token is unusable, every indirect path is closed, or the business process still works.

Step 10: Monitor and close the loop

Watch for token reuse, automatic reauthorization, recreated credentials, failed jobs, support issues, and unexpected fallback paths. Record the outcome, evidence, owner, and next review date. If the result differs from the plan, use the prepared recovery path or escalate.

Safe remediation and rollback

Revoking a grant can be the right action and still cause an outage. Before changing access, preserve enough state to understand what existed, why it existed, and how the approved workflow can be restored if new information appears.

This is one of the most important lessons we learned while building autonomous remediation at Offroad. Executing the final change is often the simplest part. The harder engineering problem is establishing enough context to make the change safely, limiting the action to what was approved, verifying its real effect, and preparing for the possibility that the organization later discovers a legitimate dependency.

A safe remediation plan should include:

1. The exact target. Record the application, grant, credential, identity, scope, resource, and environment affected.
2. The reason for change. State the risk and the evidence supporting the decision.
3. The expected result. Define which access should stop and which business function should continue.
4. The approval boundary. Identify who may authorize the action and whether additional review is needed for production or sensitive data.
5. A recovery path. Document how access can be restored or replaced, who can approve that step, and how long recovery is expected to take.
6. Verification tests. Test both the security outcome and the legitimate workflow.
7. Post-change monitoring. Watch for reauthorization, retries, failures, and alternate access paths.

Recovery is not always a one-click rollback. A revoked refresh token may require the user or administrator to authorize the application again. A deleted secret may need to be recreated and redistributed. A narrowed grant may require a new approval. In some systems, revocation and reporting also take time to propagate. The team should describe the recovery path honestly instead of promising universal reversibility.

For a deeper treatment of preserving state, validating the result, and preparing a controlled path back, see Safe Identity Remediation: Why Recovery Must Begin Before the Change.

Provider behavior matters. For example, Microsoft documents separate paths for reviewing and revoking delegated and application permissions in Entra ID, while Google Workspace lets administrators classify app access and warns that restricting a service can revoke existing tokens for apps that are not trusted. Always test the provider-specific procedure and its operational effect before applying it broadly.

See Microsoft's application-permission review guidance and Google Workspace app-access controls for examples.

Continuous governance controls

AI-agent access should be evaluated throughout its lifecycle, not only when the agent is deployed or when an annual review is due.

Before access is granted

• require a named owner and documented purpose
• restrict user consent according to risk and provider capability
• review the application's publisher, redirect URIs, credential model, requested scopes, and data handling
• prefer narrowly scoped and resource-specific access
• define allowed environments, actions, and data classes
• require stronger approval for tenant-wide, destructive, or administrative permissions

While the agent is active

• connect grants with runtime activity and business context
• detect new agents, credentials, scopes, and connected systems
• compare actual use with intended purpose
• monitor credential age, storage, rotation, and exposure
• identify dormant access and unexplained changes in behavior
• reassess blast radius when the owner, workflow, or downstream systems change

When access changes or ends

• right-size or revoke permissions when the task no longer requires them
• rotate or invalidate associated credentials
• remove orphaned application objects, assignments, and service identities where appropriate
• verify that effective access is removed
• verify that approved workflows still function
• retain the decision and outcome as audit evidence

The goal is not to generate a larger queue of findings. It is to turn connected evidence into a decision, complete the approved action, and verify what happened.

Continuous evaluation also matters because identity misuse can appear legitimate when each event is viewed alone. Why Identity Attacks Look Normal examines how access, activity, and business context help distinguish a valid-looking action from one that requires investigation.

Questions to ask an AI-agent or OAuth security platform

A platform evaluation should begin with the access relationships and workflows the product can support, not with the category name on the slide.

Discovery and coverage

1. Which identity providers, SaaS applications, cloud platforms, developer tools, and agent frameworks can the product inspect?
2. Can it discover user-delegated grants, administrator consent, application permissions, service accounts, service principals, API keys, tokens, and workload identities?
3. Can it connect one agent to multiple underlying identities and credentials?
4. How quickly does new or changed access appear, and what data is unavailable because of provider limits?

Context and investigation

5. Does the product show who granted access, who owns the agent, why it exists, and which workflow depends on it?
6. Can it calculate effective and indirect access, or does it display assigned scopes only?
7. Does it connect permissions with runtime activity across systems?
8. Can an investigator see the resources reached, actions performed, and evidence supporting the risk decision?
9. How does the product distinguish unusual but legitimate agent behavior from activity that conflicts with purpose or policy?

Remediation and control

10. Which changes can the product execute, and which require a separate tool or manual action?
11. Can teams limit a change to a permission, resource, user, credential, or environment instead of disabling the entire application?
12. How are approvals, separation of duties, maintenance windows, and policy exceptions enforced?
13. Does the product preserve prior state and explain what might break before a change?
14. How does it verify effective access after remediation?
15. What recovery options exist when a legitimate process fails?
16. Is every recommendation, approval, action, verification result, and exception recorded?

Ask vendors to demonstrate these workflows using the systems and permission types in your environment. A feature marked “supported” may mean discovery through an API, a recommendation without execution, or complete remediation with verification. Those are materially different capabilities.

How we approach AI-agent access at Offroad

At Offroad, we connect AI agents, OAuth applications, tokens, service accounts, and other non-human identities to ownership, permissions, activity, connected systems, and business context. Our agents are designed to discover identity risks, investigate whether access and activity make sense, and either remediate policy-approved issues or route the decision to the appropriate person with the investigation context prepared. Much of that context today lives as tribal knowledge scattered across Slack threads, tickets, and the people who originally set up the integration — our agents capture it directly so it isn't lost when an owner changes roles or moves on.

Our aim is to move beyond a static inventory. Security teams should be able to understand what an agent is supposed to do, what it can actually reach, how it is using that access, what could break if the access changes, and whether the remediation produced the intended outcome. As that track record builds, our agents move from investigation to auto-remediation with confidence, closing out policy-approved fixes without waiting on a person for every low-risk decision.

Learn more about Offroad's approach to AI-agent and non-human identity security, how the platform works, and the systems Offroad connects with.

Technical FAQ

What is the difference between an OAuth grant and an access token?

An authorization grant represents permission for a client to access protected resources. The client exchanges the grant for an access token. The access token is the credential presented to the resource server. In enterprise consoles, “grant” may also be used more broadly for the stored consent relationship between an application, an identity, and a set of permissions.

What is a refresh token?

A refresh token is a credential a client may use to obtain new access tokens after an access token expires or becomes invalid. Because it can extend access without repeating user interaction, it requires strong protection, appropriate lifetime controls, and revocation or rotation support. RFC 9700 recommends sender constraint or refresh-token rotation for public clients and expiration after inactivity.

Are OAuth scopes the same as effective permissions?

No. Scopes describe the access requested or represented by a token, but effective access can also depend on the delegating user's permissions, application roles, tenant configuration, resource-specific policy, group membership, and other authorization systems. Investigators should map the entire access path.

Are all AI-agent permissions OAuth permissions?

No. Agents may also use service accounts, workload identities, API keys, personal access tokens, certificates, application secrets, session tokens, or credentials stored by an automation platform. Governance should begin with the agent and follow every access method it uses.

Is a broad scope always dangerous?

A broad scope creates more potential impact, but risk depends on the resources exposed, the identity behind the grant, runtime use, credential protections, business purpose, and available controls. Scope is an important signal, not a complete risk decision.

Is an unused permission safe to remove?

Not automatically. It may be unnecessary, but it may also support an infrequent critical process or appear unused because logs are incomplete. Confirm ownership, dependencies, observation coverage, and a recovery plan before removal.

Does revoking an OAuth grant invalidate every token immediately?

Behavior varies by provider and token type. Revocation may invalidate a grant, an individual token, refresh capability, or a broader set of related credentials. Reporting and enforcement can also propagate on different timelines. Verify the provider's behavior and test that the protected resource rejects the access.

What is the safest way to remediate a risky grant?

Use the smallest change that addresses the risk. Narrow the scope or resource boundary when possible, rotate exposed credentials, change the delegated identity, or revoke the grant when the relationship is no longer justified. Record the prior state, obtain the required approval, verify effective access, test the legitimate workflow, and monitor for reauthorization or failure.

How often should AI-agent access be reviewed?

Review frequency should reflect risk, but high-impact agent access should also be monitored continuously for changes in ownership, permissions, credential state, runtime activity, dependencies, and purpose. A periodic certification alone can miss meaningful changes between review dates.

What evidence should be retained for audit and incident response?

Retain the agent and application identifiers, owner, purpose, authorizing identity, consent type, scopes or roles, credential metadata, relevant activity, risk decision, approval, change details, verification results, recovery actions, exceptions, and timestamps. The record should explain not only what changed, but why the team considered the action safe.

Conclusion

AI-agent access cannot be governed as a list of applications and scopes. Enterprises need to connect each agent to the identity it uses, the authority behind its grants, the resources it can reach, the activity it performs, the workflows that depend on it, and the business purpose that justifies it.

That context changes the decision from “Is this scope risky?” to “Does this access make sense for this agent right now, and can we reduce the risk without losing control of the outcome?”

The organizations that can answer that question continuously will be better prepared to adopt useful agents without allowing delegated access to become an unmanaged attack path.

Primary references

• OAuth 2.0 Authorization Framework, RFC 6749
• OAuth 2.0 Security Best Current Practice, RFC 9700
• Microsoft Entra: Review permissions granted to enterprise applications
• Microsoft identity platform: User and admin consent overview
• Google Workspace: Control which apps access Google Workspace data
• Google OAuth app verification

‍