智能体干了活,审计日志却说不出是谁下的指令
The agent did the work. The audit log couldn’t say who asked.
CloudBolt 审查客户与潜在客户环境中的 MCP 访问策略时发现,超过 20% 的策略已损坏或缺失,多数 MCP server 运行在个人 token 而非服务账号上。CloudBolt 的 Shawn Petty 与 Mike Bombard 将于 10 月 27 日演示如何把智能体行为关联到现有身份提供商、限制其可触碰的资源并读取审计日志。
正文
当前显示原文,中文全文译文尚未就绪。
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.
You may opt out at any time.
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 .