TL;DR: A Microsoft Copilot Studio agent connected through Zuma can still be stopped at runtime when policy, intent deviation, and anomaly controls evaluate each tool call separately, even though the agent has valid credentials and authorised tools, according to Saviynt. The real shift is that access approval is no longer enough; trust has to be re-evaluated at execution time.
At a glance
What this is: This is a walkthrough of runtime defense in depth for an AI agent, showing how separate controls block destructive, semantically risky, and anomalous tool calls.
Why it matters: It matters because identity teams cannot treat an AI agent like a static service account; authorisation, purpose, and behaviour all need separate governance gates.
Context
The core governance gap is that a granted AI agent can still make unsafe runtime decisions after authentication and authorisation succeed. Traditional access control answers whether the identity may reach a system, but it does not judge whether a specific action five minutes later still fits the approved purpose. That leaves a gap between setup-time permission and execution-time trust.
In this example, the agent acts through Microsoft Copilot Studio and reaches Google Workspace and Salesforce through a gateway that evaluates each call at the moment it is made. The important identity question is not only whether the agent is registered, but whether its behaviour stays within policy, intent, and baseline expectations once it starts chaining tools.
Key questions
Q: What fails when an AI agent has valid credentials but unsafe runtime discretion?
A: Setup-time authorisation fails because it answers only whether the identity may connect, not whether a later action still fits the approved purpose. With AI agents, the risky decision happens inside the session, after the token has already been accepted. That is why runtime policy, intent review, and behavioural checks must govern the actual call, not just the login event.
Q: Why do authorised agent actions still create security risk?
A: Because authorization alone does not prove the action was appropriate. An agent can use valid credentials to reach systems it is allowed to access while still performing a semantically unsafe task, such as exfiltrating data or deleting resources. The risk comes from combining legitimate access with manipulated intent, which many traditional tools are not built to judge.
Q: What are the signs that AI agent drift controls are not mature enough yet?
A: If every unfamiliar tool call is blocked immediately, the baseline is probably too immature to distinguish normal learning from suspicious drift. Mature controls can separate new but acceptable behaviour from genuinely abnormal sequencing. Until that distinction is reliable, monitor mode gives better evidence than hard enforcement.
Q: How should teams govern AI agent tool access across policy and behaviour layers?
A: Use policy for explicit prohibitions, intent analysis for purpose, and anomaly detection for novelty. Do not treat these as overlapping versions of the same control. They answer different questions, so governance should assign ownership to each layer and test them against distinct failure modes.
Technical breakdown
Why setup-time authorisation is not enough for AI agents
An AI agent can hold valid credentials and still produce unsafe actions because the decision point has moved from provisioning to runtime. A traditional allow decision assumes the identity’s future behaviour is already knowable, but agentic systems assemble actions from prompts, context, and model interpretation. That means the same authorised tool can be used for legitimate work one moment and a harmful sequence the next. In this architecture, access control must separate identity authentication from action approval, otherwise a valid token becomes a proxy for unlimited intent. The important mechanism is not the credential alone but the call context attached to each invocation.
Practical implication: evaluate AI agent access at each tool call, not only when the agent is onboarded.
Policy, intent deviation, and anomaly detection do different jobs
Policy controls structural permission, intent deviation controls semantic purpose, and anomaly detection controls behavioural novelty. Policy can stop an explicitly forbidden action, such as a destructive Salesforce delete. Intent analysis can stop a permitted sequence that serves the wrong purpose, such as staging sensitive CRM data for unnecessary disclosure. Anomaly and drift detection catch unfamiliar behaviour when neither policy nor purpose looks obviously wrong. These layers are not substitutes for one another. They form different evidence tests for the same runtime event, which is why one authorised agent can still be stopped multiple times without contradiction.
Practical implication: do not collapse policy, semantic review, and drift monitoring into one control because each catches a different failure mode.
Why tool-level permissions still need purpose-aware controls
Tool-level access answers a narrow question: can the agent invoke this function? That is necessary, but it is not enough for enterprise governance because many harmful actions are composed from individually permitted steps. A read-only Salesforce query, a draft email, and an internal recipient may all be allowed separately while still creating an inappropriate exfiltration pattern. Purpose-aware controls look at combinations, not just endpoints. That is the difference between authorising a function and authorising an outcome. For AI agents, the risk lives in composition, because the model decides how to sequence otherwise legitimate tools.
Practical implication: review tool combinations and action sequences, not just the allow-list for each individual connector.
Threat narrative
Attacker objective: The objective is to induce an AI agent to use its legitimate access for destructive, disclosed, or anomalous actions that the organisation would not approve in context.
- Entry occurs when the agent receives a prompt or context that drives it toward an unsafe tool call, even though it holds valid credentials and authorised access.
- Escalation appears when the agent combines individually allowed actions into a harmful sequence, such as querying sensitive data and staging it for broader disclosure.
- Impact is prevented when runtime layers block the action before the agent can delete records, exfiltrate data, or cross the behavioural boundary.
- The same pattern shows why the control problem is not authentication failure but approval of the wrong action at the wrong moment.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime authorisation is becoming the real control plane for AI agents. Once an agent holds valid credentials, the security question shifts from identity admission to action governance. That is a different problem from human SSO or static NHI access because the model decides what to do next at execution time. Practitioners should treat each tool call as a governed event, not a by-product of a trusted session.
Purpose-aware controls are now a first-class identity requirement. Policy can say what an agent may touch, but it cannot by itself decide whether a permitted action still serves the approved task. That is why intent deviation belongs beside traditional authorisation rather than inside it. The implication is that identity governance for agents must evaluate semantics, not just permissions.
AI agent access creates an identity blast radius when composition is unrestricted. A sequence of individually valid calls can create a disclosure, deletion, or automation outcome that no single control would flag in isolation. That means the governance unit is no longer the request or the token, but the action chain. Practitioners need to think in sequences, not isolated approvals.
Access review assumptions were designed for stable access, not ephemeral runtime decisions. Access review processes assume access persists long enough to be observed, certified, and revoked. That assumption fails when an agent can acquire valid access and use it in a prompt-shaped decision cycle, because the risky choice is made after the review boundary. The implication is that review cadence alone cannot protect agentic systems.
Defense in depth for agents is now an identity governance pattern, not just a security pattern. The layered model shown here aligns policy, semantics, and behaviour because no single checkpoint can see every kind of misuse. That structure belongs in agent governance design, not as an optional add-on. Practitioners should map control ownership across IAM, security engineering, and application teams before agent rollout.
From our research library:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Top 10 Agentic AI Identity Issues
What this signals
Identity blast radius: AI agents widen the meaning of privilege because one session can contain multiple legitimate tool calls that add up to an unsafe outcome. That means the programme question is no longer just whether access was granted, but whether the chain of permitted actions stayed within the intended boundary.
Governance teams should expect the centre of gravity to move from static entitlement reviews toward runtime evaluation, with policy, purpose, and drift all checked separately. That shift is especially important where agent actions can touch CRM, file, email, or calendar systems through delegated connectors.
The operational lesson is simple: if a control only understands who authenticated, it will miss why the action happened and how the sequence unfolded. Agentic systems need controls that understand all three.
For practitioners
- Define action-level deny rules for high-risk agent tools Block destructive or irreversible functions at the gateway layer, even when the agent has valid credentials and the user behind it is authorised for related work.
- Separate structural permission from semantic approval Use intent analysis to evaluate whether a permitted sequence still matches the agent’s declared purpose, especially when the agent chains read and write tools together.
- Baseline normal agent behaviour before enforcing drift controls Keep drift and anomaly checks in monitor mode until you have enough history to distinguish ordinary work from new tool use or unusual sequencing.
- Inventory every tool connection before production rollout Document which gateways, MCP targets, and downstream SaaS systems the agent can reach so you can assign governance responsibility to each control layer.
Key takeaways
- AI agents can still be risky even when every credential check passes, because the unsafe decision often happens after access is granted.
- The article demonstrates three distinct runtime stops, showing that policy, intent, and drift checks each catch a different class of misuse.
- For practitioners, the control objective is to govern the action chain, not just the login event or the connector allow-list.
Key terms
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Intent Deviation: Intent deviation is the point at which an AI agent remains authenticated and technically authorised but begins acting outside its declared purpose. It captures behavioural drift across tools, data access, and execution paths, which is why it matters more than a simple permission snapshot for runtime governance.
- Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org