返回资讯中心
外部精选
云计算
#容器平台#AI Agents#Compliance#Platform Engineering#Security

The agent did the work. The audit log couldn’t say who asked.

More than 20 percent of the MCP-related access policies that Shawn Petty’s team reviewed across customer and prospect environments were

The New StackTNS Staff2026/10/13 · 13 天前6 分钟阅读

以下正文同步自 The New Stack,版权归原站所有,已转换为易读排版。

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. REGISTER NOW FOR THIS WEBINAR You have successfully registered for the webinar. 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. In this live conversation, the CloudBolt team will explain how agents end up with access nobody approved, then show how to trace that access back to a person with CloudBolt: linking agent activity to your existing identity provider, setting limits on what an agent can touch, and reading the audit trail that results. Live attendees can ask these experts questions in real time. Register today to join us! You’ll learn:

  • How to tie agent activity back to your existing identity provider instead of building a parallel system
  • Which infrastructure actions an agent should be allowed to take without a human signing off
  • What a usable audit trail for agent behavior contains, and how to keep one without slowing teams down
  • A live trace of one agent’s credentials and actions, from the task it ran to the person responsible Can’t join us live? Register anyway, and we’ll send you a recording after the session. By registering, you consent to receiving email communications from The New Stack and CloudBolt. The post The agent did the work. The audit log couldn’t say who asked. appeared first on The New Stack.

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →