90% of AI agents are over-permissioned. Learn how to enforce least privilege for AI agents at runtime, not just configuration, with this step-by-step security guide.
Security teams cannot enforce least privilege for AI agents they do not know exist. One enterprise security team discovered 377 Copilot agents in their environment through a structured assessment. None of those agents were tracked by the security team before that assessment began.
The inventory problem is the prerequisite problem. Before any permission scoping can happen, security teams need a complete AI agent inventory that answers these questions for every agent in the environment:
Inventory FieldWhy It Matters for Least PrivilegeAgent name and platformDetermines which permission model appliesCreator and current ownerIdentifies orphaned agents with inherited credentialsConnected SaaS applicationsDefines the blast radius perimeterInvocation scope (org-wide, public, restricted)Flags agents accessible beyond intended usersMCP server connectionsSurfaces unsanctioned tool access pathwaysLast active timestampIdentifies dormant agents still holding live credentials
Shadow agents (those deployed without IT or security oversight) will not appear in any native platform dashboard by default. Achieving a single pane of glass across platforms including Microsoft Copilot Studio, Salesforce Agentforce, Amazon Bedrock, n8n, and ChatGPT Enterprise requires a purpose-built AI agent security approach, not manual spreadsheet tracking.
Here is the core problem with every configuration-only approach to least privilege for AI agents: the configuration tells you what the agent is set up to do. Effective authority tells you what the agent can actually do inside each connected SaaS application after all entitlements resolve.
Those two things are frequently not the same.
A Copilot Studio agent may be configured with a connector scoped to "read calendar events." That same connector, after OAuth grant resolution inside Microsoft 365, may carry permissions to read emails, access SharePoint files, and query Teams messages. The configuration looks scoped. The effective authority is not.
Ghost chasing happens when security teams review theoretical configuration signals with no runtime evidence of what authority was actually exercised. The shift that matters is from "what could this agent do" to "what did this agent actually do, and what can it still do right now."
Mapping effective authority requires correlating:
This correlation is what produces runtime truth. For a deeper look at how this authority mapping works in practice, the AI Agent Security Risks resource covers the key divergence points between policy and reality across major platforms.
With an inventory in place and effective authority mapped, the next step is prioritization. Not every over-permissioned agent carries equal risk.
The scale of the problem is significant. Across enterprise deployments, 90% of agents hold excessive privileges, with the average agent carrying roughly 10 times more access than its actual workflow requires. That is not a fringe problem. It is the baseline condition.
Over-permissioned status alone is a medium-severity finding. The critical-severity findings come from toxic combinations: multiple risk factors present simultaneously on a single agent.
Examples of toxic combinations to flag immediately:
Each individual factor may score as medium. Combined, they represent a critical blast radius that a compromised or misused agent could detonate across your SaaS environment. Toxic risk combination scoring provides a structured approach for prioritizing remediation.
Security teams should also review OAuth scope and permission hygiene as part of this identification step, since OAuth grant resolution is a primary mechanism through which theoretical configuration diverges from effective authority.
Once over-permissioned agents are identified, the remediation work begins. Task-level least privilege means an agent holds only the permissions required to complete its defined workflow, nothing more, and those permissions are scoped as narrowly as the platform allows.
A practical scoping framework:
Define the agent's exact task scope. What actions does this agent need to take? What data does it need to read? What data does it need to write? Document this explicitly before touching any permission settings.
Audit current OAuth scopes against task requirements. For every connected credential, compare the scopes currently granted against the scopes the task actually requires. Remove anything that does not map directly to a documented task requirement.
Replace broad role assignments with scoped permissions. An agent handling lead routing in Salesforce does not need system administrator privileges. An agent summarizing meeting notes in Copilot does not need access to SharePoint financial archives. Scoped permissions reduce blast radius before any enforcement layer is applied.
Apply time-bound or purpose-specific authorizations where the platform supports it. Standing permissions create standing risk. Ephemeral, task-scoped access grants limit the window of exposure if an agent credential is compromised or abused.
Restrict invocation scope. An agent accessible org-wide or publicly is an agent any user (including users who should not have access to the underlying data) can invoke. Restrict invocation to the specific user groups or service contexts the agent was designed to serve.
For platform-specific guidance, the Secure Salesforce Agentforce and Secure Microsoft Copilot resources cover the permission scoping mechanics for two of the highest-risk enterprise platforms.
Two specific agent configurations consistently produce the highest-severity privilege escalation findings. Both require dedicated remediation steps beyond standard permission scoping.
Maker mode is the configuration state where an agent executes using the credentials of its creator rather than the credentials of the user invoking it. The mechanism works like this: a user without Salesforce access invokes a Copilot agent built by a Salesforce administrator. The agent runs on the administrator's embedded credentials. The invoking user can now extract CRM data they were never provisioned to see. The agent did exactly what it was designed to do. Your IAM controls were bypassed entirely.
Maker mode with sensitive data access is the single most dangerous default configuration in enterprise agentic deployments today. Identifying every maker mode connector, correlating the creator's privilege level against the invoker's provisioned access, and flagging the mismatch is a non-negotiable step in any least privilege program for AI agents.
An orphaned agent is an agent whose creator or owner account has been disabled, but the agent continues running with the inherited credentials. This is the agentic equivalent of a stale service account, except the agent may be actively invoked by other users or automated workflows, moving data at machine speed with credentials that belong to an account no longer under any active management.
Every agent whose owner account is disabled must be reviewed immediately. The credential chain must be evaluated, and the agent must be either re-owned with documented accountability or decommissioned.
The AI Agent Governance framework provides a structured approach for establishing ownership accountability across the full agent lifecycle.
Configuration-time scoping reduces the blast radius. Runtime enforcement is what prevents a probabilistic agent from exceeding its intended boundaries when it deviates from expected behavior.
This is the critical distinction. AI agents are probabilistic by design. They do not follow deterministic execution paths. An agent scoped to read customer records may, through action chaining, sequence a series of tool calls that results in writing data, triggering downstream workflows, or accessing connected systems the original scope never contemplated. Configuration cannot predict or prevent that. Deterministic guardrails can.
Deterministic guardrails are fixed, predictable enforcement rules applied to agent behavior at runtime. They do not rely on the agent's own judgment about what it should do. They enforce boundaries regardless of what the agent decides to attempt.
The target enforcement state for least privilege at runtime includes:
Action-level blocking: specific tool calls or data access patterns outside the agent's defined task scope are blocked before they complete, not logged after the fact.
Identity correlation at invocation: the invoking user's provisioned access is checked against the agent's effective authority before the agent executes. Maker mode mismatches trigger alerts or blocks.
Cross-platform action chaining detection: agent-to-agent communication pathways that would allow a limited-permission agent to access data through a higher-permission agent are flagged as confused deputy risk.
Continuous runtime monitoring: every tool call, data access event, and external integration the agent performs is captured and correlated against its defined task scope in real time.
Configuration is not reality. Runtime truth requires runtime enforcement.
Runtime guardrails for Microsoft Copilot are on the roadmap for late Q1 2026; guardrails for other platforms follow in Q2 2026. In the meantime, detection and monitoring at the runtime layer provide the evidence base that enforcement will build on. The goal is connector-free deployment so security teams can act without waiting for IT to provision integrations across every platform in the stack.