AI agents have moved past answering questions. They pull records, call APIs, update workflows, escalate cases, and sometimes kick off real business actions with very little human involvement. That raises a question no accuracy benchmark can answer: when a swarm of agents acts across your systems, who is accountable?
In regulated industries, “the model” isn’t an acceptable answer. Banks, insurers, and healthcare providers need a chain of custody they can verify: which agent acted, for whom, under what authorization, with which tools and data, and whether it stayed within policy. Microsoft Entra supplies the identity and access foundation. IBM’s watsonx Orchestrate and watsonx.governance turn runtime activity into evidence an auditor can use. Together they make agent autonomy deployable without making it unaccountable.
The real blocker isn’t intelligence
Enterprises aren’t holding back because agents can’t finish tasks. They’re holding back because an agent that can act can also create risk at machine speed.
Picture a claims agent that retrieves policy documents, calculates coverage, updates a case, and triggers a payment. Or a financial-services agent that pulls customer records, reconciles transactions, and starts a remediation workflow. In both cases, getting the output right is only part of the story. The organization also has to be able to reconstruct the decision later: which agent acted, whose authority it used, what data it touched, which model version produced the result, and whether a human-approved policy boundary was enforced.
IBM frames the requirement in similarly practical terms. Every agent needs a verified owner, access and autonomy limited to its business purpose, controls enforced before consequential actions, and an evidence trail. Microsoft makes the same point from the identity side: agents need unique, traceable identities, not anonymous access to enterprise systems.
So the “rogue agent” problem is less about a malicious AI and more about an unattributable AI: an agent whose actions can’t be reliably bounded, monitored, investigated, or reversed.
Why agent swarms break old controls
Traditional security assumes a simple chain. A user authenticates, opens an application, and does something. Agentic AI breaks that.
One user request can set off a long run of agent-to-agent calls. A customer-facing agent hands work to a claims agent, which calls a document-retrieval agent, which queries a policy database, which triggers a workflow system. Every hop adds a new identity, a new permission boundary, a new data-access decision, and a new place for things to go wrong.
That creates a handful of governance headaches:
- Delegated authority: An agent can act on behalf of a user while keeping its own system access.
- Agent-to-agent escalation: One agent’s request can become another agent’s authorization to act.
- Credential sprawl: Shared service accounts and static keys make it hard to tell one agent’s actions from another’s.
- Shadow agents: Agents built outside central governance can stay alive long after their business purpose ends.
- Runtime drift: An agent that was safe at deployment can behave differently after a model update, a tool change, or a new data source.
- Audit gaps: Logs that capture only the final API call can miss the agent, user, tool, and decision context an investigation needs.
Microsoft calls this agent sprawl: agents deployed without oversight, kept past their useful life, or given more permissions than they need. IBM’s approach also focuses on visibility into agents with no identity, agents with no owner, and agents still running on static or shared credentials.
Chain of custody for AI decisions
It helps to borrow an idea from regulated operations: chain of custody. Every consequential action should leave enough evidence behind to say who did it, why they were allowed to, what they touched, and whether it stayed within policy.
| Oversight question | What the architecture must capture |
|---|---|
| Who acted? | The specific agent identity and the human principal it represented |
| Why could it act? | Owner, sponsor, business purpose, entitlement, and authorization scope |
| What did it access? | Tool, connection, API, dataset, and system involved |
| What did it decide? | Prompt, retrieved context, model version, output, and action taken |
| Was it within policy? | Applicable control, evaluation metric, threshold, and enforcement result |
| Can it be stopped? | Kill switch, session termination, permission revocation, and incident workflow |
IBM’s Agent Identity capability answers the first question with two names: the agent that acted and the person it acted for. Its audit logs record the event, the connection and tool involved, and the user behind the action, with identifiers that support structured investigation.
Microsoft attacks the same problem through agent identities. Each agent gets its own identity, an assigned owner and purpose, and access controls matched to what it actually needs. An opaque piece of automation becomes a governable enterprise principal.
Microsoft Entra: the identity control plane
Microsoft Entra Agent ID extends identity, access, and governance controls to AI agents. It doesn’t treat agents as generic apps or pretend they’re human users. Instead, it gives them purpose-built identity constructs that can be authenticated, authorized, governed, and protected.
Every agent gets an identity
With Entra Agent ID, organizations can assign identities to agents, discover them across the environment, and manage details like capabilities, tasks, and protocols in one place. That matters because an agent you can’t identify is an agent you can’t responsibly own, review, or revoke.
The platform supports standard protocols, including OAuth 2.0, Model Context Protocol (MCP), and agent-to-agent (A2A) communication. In practice, identity can travel along the agent chain instead of vanishing at the first tool call.
Ownership stops being optional
Every agent identity needs a human sponsor who is accountable for its purpose and lifecycle decisions. If that sponsor leaves the company, lifecycle workflows can hand sponsorship to someone else automatically, so a human is always on the hook.
That’s a real shift. It closes off a familiar failure: an automation sits in production, keeps access to sensitive systems, and nobody can say who owns it when something goes wrong.
Access is bounded and revocable
Entra brings the usual identity-governance tools to agents: access packages, approval workflows, time-bound access, expiration, and auditability. Conditional Access can weigh an agent’s context and risk before granting access, including agent-risk signals from Microsoft Entra ID Protection.
Agent identity blueprints help at scale. Admins define Conditional Access rules, permissions, and governance controls once, and every current and future agent instance inherits them. Disabling a blueprint can block a whole class of agents in a single step.
Microsoft also restricts certain high-privilege roles for agent identities. Agents can’t be assigned roles like Global Administrator, Privileged Role Administrator, or User Administrator. Only lower-privilege roles such as Reader are available.
The Entra principle: an agent can be autonomous in how it carries out a task, but never in its identity, its entitlements, or whether it can be revoked.
Microsoft Defender: oversight at runtime
Identity controls decide whether an agent should be allowed to act. Runtime protection decides whether it’s behaving safely while it acts.
Microsoft Defender offers real-time protection meant to stop AI agents from taking unsafe actions during runtime, while giving organizations control over agent behavior. Defender for Cloud adds threat protection for AI services, surfacing threats that could affect generative AI applications and workloads.
The distinction is important. A compromised credential, a prompt-injection attempt, or an unexpected tool call can happen even when the agent has legitimate access. If you only check permissions at login, you’re not covered. You need continuous inspection across the agent’s execution loop.
In the combined model:
- Entra answers: Is this agent authorized to access this resource?
- Defender answers: Is this agent doing something unsafe right now, and can we stop it before harm occurs?
Security stops being a static gate and becomes a live control plane.
IBM watsonx: from activity logs to governance proof
Microsoft’s stack establishes who an agent is and what it may do. IBM’s covers the other half of the problem: whether the agent’s behavior can be governed, measured, and evidenced across a business process.
watsonx Orchestrate as the agentic control plane
IBM watsonx Orchestrate gives enterprises a central layer to observe, govern, and optimize AI agents, including agents built elsewhere and imported into its runtime. Its Agent Identity capability gives each agent a verifiable identity, registered in IBM Verify or Microsoft Entra, with named owners. Security teams get a view of which agents exist, what they can access, and what they did.
When a user runs an agent, the agent calls enterprise systems as itself, through an OAuth token exchange scoped to that specific user and agent. This detail matters: it keeps the human principal and the agent principal separate instead of folding both into one shared credential.
Audit logs create the evidence trail
Every agent with an identity gets its own access log. Each event records what happened, which connection and tool were involved, and which user the agent acted for, along with the identifiers needed to trace it.
For an auditor, that changes the job. Rather than stitching together partial logs from several systems, they can filter by event type, open a structured investigation view, and pass raw event data into existing security tools.
The kill switch makes oversight actionable
A governance system that can only describe a problem after the fact isn’t finished. IBM’s Agent Identity includes a kill switch that undeploys an agent from the live environment and ends its active sessions in one step.
Before shutdown, watsonx Orchestrate shows which collaborator agents might be affected, so teams understand the blast radius before they act. It’s a small design choice with real weight: incident response has to be fast, but it also has to be informed.
watsonx.governance: proving controls actually worked
Policies are easy to write. Proving they were enforced is the hard part.
IBM watsonx.governance Enforcement Tracking links watsonx Orchestrate to governance controls, automatically collects agent evaluation metrics, and records them as enforcement evidence. It’s built to close the gap between a documented policy and ongoing proof that the policy is being met.
It works in three stages:
- Connect operational AI to governance controls: Organizations tie agents to governance use cases and controls across development and production.
- Collect evidence continuously: Production agents are evaluated on a schedule, while agents still in development can be evaluated on demand before deployment.
- Verify controls automatically: Metrics are compared against business-defined governance thresholds, and pass or breach results are recorded directly in watsonx.governance.
Teams can track metrics like hallucination, helpfulness, and toxicity, with results captured and stored automatically as governance evidence. Compliance, risk, and audit teams end up with a constantly updated record that shows where controls held and where they failed.
The combined oversight loop
The best way to see the Microsoft and IBM combination isn’t as rival products. It’s as complementary layers in a closed oversight loop.
Human intent
↓
Agent identity and authorization — Microsoft Entra
↓
Policy-bound business execution — IBM watsonx Orchestrate
↓
Runtime inspection and intervention — Microsoft Defender
↓
Evaluation metrics and governance evidence — IBM watsonx.governance
↓
Audit, investigation, revocation, or agent redesign
↓
Updated policies, blueprints, and lifecycle controlsEach layer answers a different enterprise question:
| Layer | Core question | Primary contribution |
|---|---|---|
| Microsoft Entra | Who is this agent and what may it access? | Agent identity, ownership, least privilege, lifecycle, Conditional Access |
| Microsoft Defender | Is the agent behaving safely in real time? | Runtime protection, risk signals, prevention of unsafe actions |
| IBM watsonx Orchestrate | How does the agent operate within the business process? | Agent identity, audit logs, token exchange, kill switch |
| IBM watsonx.governance | Can the organization prove the agent met policy? | Evaluation metrics, enforcement evidence, control-to-agent mapping |
Put together, these layers give you something more useful than a dashboard: a continuous chain of custody for agentic decisions.
Why finance and insurance need this now
Financial services and insurance are natural proving grounds. Their agent use cases tend to involve customer impact, money movement, regulatory obligations, and actions that can’t be undone.
Take a governed insurance agent. It might be allowed to retrieve policy documents and calculate a coverage determination, but required to escalate to a human before issuing a payment above a set threshold. Its identity would be registered and owned. Its access would be time-bound. Its tool calls and retrieved documents would be logged, and its evaluation metrics would be checked continuously against governance thresholds.
That doesn’t remove risk. It makes risk attributable, bounded, observable, and reversible, which are the conditions under which legal and compliance teams can reasonably sign off on autonomy.
The explainability gap remains
Identity logs and audit trails prove what happened. They don’t always explain why a model made a particular recommendation.
So explainability has to be built in layers:
- Identity explainability: Which agent, owner, user, and tool were involved.
- Process explainability: Which workflow, policy, and approval path applied.
- Decision explainability: Which prompt, retrieved documents, model version, and output shaped the result.
- Behavioral explainability: Which evaluation metrics and thresholds were breached.
- Governance explainability: Which control was meant to prevent the issue, and whether it worked.
IBM’s governance approach deliberately moves past static documentation toward continuous evidence that policies are being enforced. Microsoft’s identity model likewise treats agent authentication and activity as auditable events.
Nobody needs to claim a model can perfectly explain its own reasoning. The goal is for an enterprise to reconstruct the decision context well enough to investigate it, challenge it, fix it, and defend it.
What CIOs and CISOs should demand
Before scaling agent swarms, enterprise leaders should insist on the following:
- Every production agent has a unique identity, a named owner, a sponsor, a business purpose, and a lifecycle status.
- Agent access is least-privilege, time-bound, approved, and reviewed regularly.
- Agent-to-agent calls are authenticated, authorized, and logged.
- High-impact actions are checked against policy before they run, not just reviewed afterward.
- Prompts, tool calls, outputs, model versions, and retrieved sources are kept in an auditable evidence trail.
- Security teams can spot anomalous behavior and block unsafe actions in real time.
- Compliance teams can map runtime metrics to specific controls and trigger governance workflows.
- Every production agent has a tested kill switch and a documented incident-response path.
- Third-party agents meet the same identity, audit, and revocation standards as internally built ones.
Autonomy becomes deployable when it becomes attributable
The future of enterprise agentic AI won’t hinge on whether agents can reason more impressively. It will hinge on whether organizations can make them accountable enough to trust, conditionally.
Microsoft Entra gives agents the identity, ownership, access boundaries, and revocation path they need to operate inside an enterprise. IBM watsonx Orchestrate and watsonx.governance give organizations the process control, audit trail, evaluation evidence, and enforcement proof to show that agents stayed within policy.
None of this promises perfectly safe agents. It promises something more valuable commercially: agents whose actions can be governed, investigated, and defended. For regulated enterprises, that’s the difference between an impressive pilot and a production-ready autonomous workforce.