Reduce AI Agent Over-Privilege

You can reduce AI agent over-privilege only after you understand how it lands there, and the mechanism is boring. A business user builds an agent in a low-code platform. They pick the broadest OAuth scope on the menu because the narrow one failed on the first try. They run it in maker mode so it inherits an admin's credentials and never breaks. Then they share it with the whole tenant. Every one of those choices optimizes for the agent working, not for the agent working safely.

Multiply that by thousands of agents spawned every week across Copilot, Agentforce, ChatGPT Enterprise, n8n, and the rest, and you get what the industry now calls machine insider risk: software holding standing credentials like an employee, with none of the joiner-mover-leaver controls that govern an actual employee. The scale is not subtle. Agents move roughly 16x more data than the humans around them, and studies put close to 90% of them in an over-permissioned state. That gap between granted and needed access is the thing you are trying to shrink.

What over-privilege actually is here

Over-privilege is the delta between an agent's granted permissions and the minimum its real workflow needs. It shows up in four recurring shapes: overly broad OAuth scopes, inherited maker-mode credentials, reused service accounts, and org-wide sharing on an agent that only ever needed a scoped audience. The quiet version is the dangerous one. An agent inherits an admin's CRM credentials in maker mode. A rep with no CRM access invokes it from a chat channel and pulls restricted opportunity data through the agent's authority. Nothing in the configuration looks wrong, which is exactly why config-only review misses it.

Why the delta matters: blast radius

Every unnecessary scope, every inherited admin token, every org-wide share widens blast radius. When an agent is compromised, misconfigured, or talked into a confused-deputy action, the damage is bounded by what that agent can reach, so shrinking reach is the most direct control you have. The Salesloft Drift campaign attributed to UNC6395 is the reference case: stolen OAuth tokens let attackers reach data across roughly 700 organizations without touching a single password. The agents involved simply had more standing authority than their task required, and that authority became the attacker's.

Configuration tells you what an agent is set up to do on paper. Effective access tells you what it can actually touch once every OAuth scope, group membership, service account, and inherited maker credential resolves inside the connected application. These are almost never the same picture. A Copilot agent's config may list three connectors; at runtime those connectors resolve to a service account with read access to every SharePoint site the creator has ever joined. The policy claims least privilege. The behavior says otherwise.

This is the difference between chasing ghosts and doing the work. A posture dashboard shows you theoretical risks with no evidence that any of them were ever exercised, by whom, or against what data. Runtime truth is the opposite: it correlates a specific agent's activity to its effective access inside the third-party app, down to which service account it used, which tables and objects it read, and which actions it took. You cannot right-size against a config page. You can right-size against that.

Not all excess access is worth your Tuesday. If you try to remediate every medium-severity finding across a few hundred agents, you will burn the quarter and change nothing that moves risk. The signal is in toxic combinations. One medium risk on one agent is noise. Three medium risks stacked on the same non-human identity is a critical, because the failure modes multiply rather than add.

The highest-signal patterns to hunt first:

• Maker mode plus sensitive data reach. The agent runs on the creator's admin credentials, and those credentials touch regulated or restricted data. Any invoker inherits that reach. This is the top-severity pattern.
• Org-wide audience plus unrestricted scope. Anyone in the tenant can invoke it, and it can reach almost anything.
• Orphaned agent with live credentials. The creator's account is disabled, but the agent keeps running on inherited tokens nobody owns.
• Public entry point plus authenticated backend. External invokers reach internal data through the agent's identity.
• Cross-platform action chains. Agent A calls Agent B calls an MCP tool, and each hop compounds effective access nobody scoped end to end.

When an agent keeps requesting scopes it never uses

A recurring over-ask usually traces to one of three causes: a platform template that defaults to broad scopes, a creator who copied a working config from a more privileged agent, or a framework that auto-negotiates the widest available scope on first token exchange. The fix is upstream, not per-agent: lock scope defaults at the platform policy level and reject broad grants at approval time, so the widest path stops being the default path.

The fear that stalls most programs is breakage. Cut the wrong scope, the agent fails quietly, a business user files a ticket, and the security team loses the mandate to touch anything. Right-sizing avoids that by starting from observed behavior instead of a policy guess.

A workflow to reduce AI agent over-privilege safely

1. Capture 14 to 30 days of runtime tool calls for the target agent.
2. Enumerate every data source, API, and tool it actually invoked, and the identity it invoked them as.
3. Map those calls back to the minimum OAuth scopes and service account roles that cover them.
4. Stage the reduction in a test tenant or in shadow mode, where the new policy logs but does not block.
5. Compare pre- and post-change call patterns for regressions.
6. Promote to production with a rollback ready.

Runtime observation is the non-negotiable input. Without it you are guessing which permissions matter, and every guess trades a breakage risk for a coverage risk.

Fix in the right order: identity, connector, runtime

Right-sizing works across three layers, and the order matters. At the identity layer, replace shared service accounts with a dedicated non-human identity per agent, so activity is attributable. At the connector layer, restrict OAuth scopes to the exact APIs the workflow calls. At the runtime layer, apply deterministic guardrails that stop calls outside the agent's declared purpose. Fixing identity without connectors leaves the same over-broad tokens in play. Fixing connectors without a runtime check gives you a policy the agent can still drift past on its next probabilistic run.

RBAC as a floor, least privilege as the target

Role-based access assigns permissions by job function; least privilege assigns them by observed task. Agents do not have a job, they have prompts, and prompts change. An agent scoped to "sales enablement" today may be asked to summarize contracts tomorrow. Use RBAC as a floor when you need policy defaults and cannot yet see runtime behavior. Move to least privilege as the target once you can watch what each agent actually calls, expanding scope only when a new observed behavior requires it. When full access is more than the task needs, narrower primitives usually cover it: scoped OAuth grants limited to specific record types, delegated identity where the agent acts as the invoker rather than the creator, just-in-time elevation released after the task, and read-only mirrors over a curated view instead of the production source.

Point-in-time reviews were designed for humans who change roles a few times a year. Agents change behavior every prompt, so a quarterly cadence is structurally too slow. A quarterly review might catch an over-privileged agent months after it was created; a continuous model catches the same agent within hours of its first anomalous tool call. When agents spawn weekly and chain actions in seconds, a 90-day gap is not a review cycle, it is a breach window.

Continuous review has a hard prerequisite: runtime telemetry. A configuration snapshot taken monthly cannot show you an agent that quietly used its inherited admin token twice last Tuesday. Only a live feed does.

Auditing what an agent actually used

An effective-access audit needs runtime evidence from the AI platform, not just the downstream app logs. The trail should carry, per action, the invoker identity, the agent identity, the tool or connector called, the target application, the objects reached, and the outcome. Correlate those over a 30-day window and the real permission footprint appears, usually much smaller than the granted one. This does not survive by hand. Ten agents can be reviewed manually; two hundred cannot. Automated correlation through an identity graph is the only approach that holds up at real agent volume.

Findings without enforcement is expensive logging. A durable program connects three stages into one control plane so evidence generates itself instead of being reassembled by hand each quarter.

1. Discover and inventory every agent, connector, and MCP tool across the platforms in scope. Inventory is increasingly commodity, so treat it as table stakes rather than the destination, and make sure it spans platforms so cross-platform chains are visible.
2. Assess effective access by correlating configuration with runtime tool calls, invoker identity, and downstream entitlements. This is where theoretical configuration turns into real risk data: which service account, which objects, which actions.
3. Decide and enforce with deterministic guardrails that can allow or block a toxic action chain before it completes, on the platforms where enforcement is live.

Where enforcement is live today, and where it is roadmap

Runtime enforcement, meaning autonomous allow-or-block on an action before it lands, is available today for Claude and Microsoft Copilot. For Agentforce, ChatGPT Enterprise, Bedrock, Vertex, Snowflake Cortex, ServiceNow, Moveworks, and n8n, the capability today is discover and govern: full effective-access mapping and policy, with runtime enforcement on the roadmap rather than in production. Being explicit about that line is part of the discipline. Claiming blocking everywhere is how programs lose trust the first time an agent does something the dashboard swore it could not.

Obsidian's role sits at the decision layer, not in the traffic path. Rather than an inline gateway, it runs an "Intel Inside" model: the effective-access engine renders the allow-or-deny decision, and the enforcement point calls it. That maps effective access across the supported platforms without demanding a separate connector for every downstream app, and it keeps the correlation, from agent activity to the objects and actions it touched, as the source of truth the enforcement decision is built on.

Who owns this

Ownership confusion is the real failure mode, because when no one owns it the most permissive path wins by default. Security engineering owns the program. IAM co-signs identity assignment and lifecycle rules. Platform owners, the Copilot admin, the Salesforce admin, the Bedrock admin, execute changes in their environments. Business sponsors approve exceptions and accept residual risk in writing. Name those roles before you have a thousand agents, not after.