AI Resilience, Part 3: The Agent Isn't the Only Agent

So far in this series, I've covered two realities of autonomous AI. The sandbox isn't necessarily the security boundary. And an agent doesn't have to go rogue to cause an enterprise incident. It just has to make the wrong call with enough authority to act on it. 

There's a third shift that makes both of those harder: the agent acting on behalf of your company may not be your agent. 

Employees already work with agents built into the apps they use every day, like Salesforce Agentforce, Atlassian Rovo, and Sierra. They also use general-purpose platforms like Claude, ChatGPT, and Gemini, which connect to more enterprise apps and tools every quarter. 

That isn't a problem in itself. It's where enterprise AI is headed. It does change the control problem, though. 

One request, many hands 

A salesperson types: "Review my pipeline and clean up the opportunities that need attention." 

From their seat, that's one request to one agent. Under the hood, it might run like this: 

Employee → Agent A → Agent B → Tool → Salesforce → Business outcome 

Every step can be legitimate. Every system can have its own security controls. The overall outcome can still be wrong. 

The reason is simple: agents can increasingly delegate. The enterprise isn't just managing access to applications anymore. It's managing authority as it moves between autonomous systems. 

Who is actually acting? 

The good news: the major platforms are already working on the first layer of this. 

• Microsoft treats agents as distinct identities in Entra, with ownership, sponsorship, access, and lifecycle controls. 
• OpenAI gives enterprises controls over connected apps, permissions, and approval requirements. 
• Anthropic offers admin controls over connectors and individual tool permissions. 
• Google Gemini Enterprise is adding governance for third-party agents, covering procurement, integration, and user access. 
• AWS has the approach I find most interesting. Bedrock AgentCore can pass a user's authorization context to downstream services, so those systems enforce the user's permissions instead of trusting the agent to make the call. 

The direction is clear. Agents need an identity. Authority needs to be scoped. Downstream systems should enforce their own permissions. 

That's real progress. It mostly covers control inside a single platform boundary. The harder problem starts when the path looks like this: 

Employee → Agent A → Agent B → Tool → SaaS application → Business transaction 

Now you've got multiple identities, multiple authorization decisions, and possibly multiple organizations involved. 

The real problem is delegated agency 

Back to the salesperson. The employee authorized the request. Agent A is authorized to work in Salesforce. Salesforce authorizes the API call. So far, so good. 

Then Agent A hands part of the job to Agent B. This is the moment the enterprise has to protect, and the principle is short: 

An agent should carry authority. It should never create authority. 

For that to hold, every delegation needs to be: 

• Explicit. Someone or something authorized it. 
• Scoped. The authority is limited to the task. 
• Traceable. The enterprise can reconstruct the handoff. 
• Revocable. The authority can be pulled back. 
• Attributable. The final action ties back to the original request. 

This applies no matter how agents connect. A2A is one emerging standard for agent-to-agent interoperability. Delegation also happens today through subagents, MCP, APIs, and proprietary platform orchestration. 

The protocol matters. The chain of agency matters more. 

Trust the vendor. Keep the accountability. 

Enterprises will use third-party agents because those vendors offer capabilities nobody wants to build in-house. The answer isn't to ban them. It's to make delegated authority explicit. 

You may trust the vendor. You may approve the integration and the agent. You still need to know the chain: Who authorized the agent? What was it allowed to do? What could it delegate? Where did that authority stop? 

Anyone in identity or third-party risk management will recognize these questions. Agents add one new wrinkle, and it's a big one: the software can choose the next hop. 

A traditional application has fixed integrations. An autonomous agent can decide which tool to use, in what order, and whether another agent should take part of the work. So the control problem shifts from managing integrations to managing chains of agency. 

300 bad changes and nobody to ask 

Say the salesperson's request goes sideways, and 300 opportunities get changed incorrectly. 

Salesforce can tell you which records have changed. The agent provider can tell you what the employee asked. Another agent might keep its own execution history. Every system has a perfectly reasonable audit trail, and the enterprise still can't answer one question that matters: what caused the 300 changes? 

This is where Uncover earns its place. The enterprise needs enough provenance to rebuild the full path: 

Human intent → Agent identity → Delegated authority → Context → Handoff → Tool → Policy → Transaction → Outcome 

Again, the goal isn't to capture a model's private chain of thought. It's to see how authority and action moved through the enterprise. Two kinds of provenance do that together: 

• Execution provenance tells you what happened. 
• Agency provenance tells you how authority moved through the chain that made it happen. 

With both, you can tell a bad input from a bad decision, an overly broad permission, an inappropriate delegation, a faulty tool, or a downstream failure. Without them, every incident becomes a forensics project spread across multiple vendors. 

Recovery doesn't stop at the app's edge 

Now picture that same agent changing data in Salesforce, kicking off a workflow in another SaaS app, emailing a customer, and creating a downstream transaction. 

No single system owns that business outcome. If the action was wrong, restoring one application probably won't fix it. Recovery might mean reversing transactions, reconciling records, restoring configuration, revoking the agent's authority, and correcting downstream state. 

Recovery follows the business outcome, not the ownership boundary of whichever agent acted. Put another way: the recovery boundary may be larger than the security boundary. That's where the third-party agent problem connects directly to AI resilience. 

The chain of agency is the new boundary 

The first wave of enterprise AI asked: can we safely give AI access to our systems? 

The next wave asks something harder: can we safely let an AI act on our behalf, and hand work to other AIs, across those systems? 

The enterprise isn't managing one agent anymore. It's managing a chain: 

Employees → 1P agents → 3P agents → Specialized agents → Tools → Enterprise systems 

So the question isn't just whether any single agent is secure. It's whether the enterprise can control, understand, and recover the chain of actions agents take in its name. That's why AI resilience has to follow the chain, all the way around the loop: Prevent, Uncover, Recover, Learn, and back to Prevent. 

AI won't always do what we expect. Resilience is about being ready when it doesn't. 

Up next: how much can it change before something stops it? 

If one agent can cause an incident, a chain of agents can multiply the impact. Part 4 gets into bounded autonomy, blast radius, and circuit breakers, and why an agent risk should be measured by more than what it can access. What matters just as much is how much of the enterprise it can change before the system steps in. 

Further reading 

• Microsoft Entra Agent ID: agent identity and lifecycle governance 
• OpenAI Enterprise connected-app controls: permissions, approvals, and connected applications 
• Anthropic Enterprise: connector and tool-level permissions 
• Google Gemini Enterprise: governance of third-party agents 
• AWS Bedrock AgentCore: passing user authorization context to downstream services 
• A2A: an emerging open standard for agent-to-agent interoperability 

(A variation of this post first appeared on Anant's Substack. Available to subscribe.)