More than 20 percent of the MCP-related access policies that Shawn Petty’s team reviewed across customer and prospect environments were broken or missing, according to a recent account published in The New Stack. In most cases, the MCP server ran on someone’s personal token rather than a service account.

At 12 p.m. Eastern/9 a.m. Pacific on Tuesday, October 27, Petty, Chief Customer Officer at CloudBolt, and Mike Bombard, Director of Global Pre-Sales Engineering at CloudBolt, will join The New Stack host Viktor Farcic for a live demo of how to trace an agent’s actions back to the person responsible for them.

What is your organization’s posture toward allowing AI agents to interact with cloud infrastructure? *

The problem, though, usually shows up after an incident: That personal token puts an engineer’s name into the audit trail for everything the agent did. Meanwhile, a shared service account puts the account’s name there instead. In both cases, the audit trail isn’t able to identify who precisely asked the agent to do the work or who approved the access it used.

Access that goes through a request, approval, and grant in the identity provider is provisioned, and the identity provider records it. Access that an agent picks up along the way is emergent: A role inherited from the service that launched it, or a developer’s own token lent out to finish a task. The identity provider holds no record of those grants, so when an agent touches something it shouldn’t, you can’t trace it back.

Source link