AI Agents Without Traceability: The Identity Hole in Your SMB

The adoption of artificial intelligence agents in cloud environments is advancing faster than the identity controls that should govern them. According to a recent publication by The New Stack, more than 20% of the access policies related to MCP (Model Context Protocol) that Shawn Petty's team reviewed in client and prospect environments were broken or outright missing. In most cases, the MCP server was running with someone's personal token, not a dedicated service account.

The data point is relevant because MCP is becoming the de facto standard for AI agents to connect to tools, databases, and cloud services. If the agent acts with an employee's personal credentials, any action it executes is logged under that person's name, even if they didn't authorize it. The result is a traceability hole: the agent did the work, but the audit log can't say who asked for it.

Why this matters in an SMB

In a small or medium-sized company, the temptation to connect an agent to a cloud service with the administrator's token is enormous. It's quick, it works, and it doesn't require setting up complex identity infrastructure. But that shortcut has consequences:

• Impossible auditing: if the agent modifies a resource, there's no way to know if it was a scheduled action, an error, or a human decision.
• Complicated revocation: if the employee leaves the company or changes roles, you have to locate all the agents that used their token before deactivating it.
• Expanded attack surface: a personal token usually has more permissions than necessary and isn't subject to automatic rotation.
• Regulatory non-compliance: depending on the sector, not being able to trace who authorized an action can be a direct problem with auditors or clients.

It's not a theoretical problem. At ForgeNEX we've seen how IT teams in SMBs start testing agents for operations tasks—checking metrics, restarting services, launching pipelines—and they do it with the token of the engineer who set up the test. When the test goes to production, no one reviews that detail.

Identity for agents: what should change

The solution involves treating agents as full-fledged identities, not as extensions of a person. This implies:

1. Dedicated service accounts: each agent must have its own identity, with minimal permissions and credential rotation.
2. Full-chain traceability: it's not enough to log what the agent did; you must log which human or system invoked it and with what authorization.
3. Explicit access policies: define what each agent can do, in which environments, and under what conditions. No inherited permissions for convenience.
4. Periodic review: the MCP policies Petty found broken or missing didn't break themselves; no one simply reviewed them after the initial configuration.

CloudBolt, Petty's company, is organizing a webinar on October 27 to demonstrate how to trace an agent's actions back to the responsible person. Beyond the event, the message is clear: if your company is deploying AI agents, identity and auditing can't be an afterthought.

What we recommend from ForgeNEX

For an SMB starting with AI agents, the order of priorities should be:

• Inventory before deployment: know what agents exist, what tokens they use, and what they have access to. Without this step, any subsequent control is worthless.
• Separate environments: agents in testing shouldn't touch production with real credentials. If they need data, it should be anonymized or synthetic.
• Start with the boring stuff: service accounts, minimal permissions, and centralized logs. It's not glamorous, but it prevents 90% of problems.
• Define who is responsible: when an agent does something wrong, who takes responsibility? If the answer isn't clear, the identity design is incomplete.

The rise of AI agents is reminiscent of the early years of the cloud: lots of experimentation, little governance, and the feeling that "we'll fix it later." But unlike the cloud, agents act on their own. A forgotten personal token on an MCP server can execute actions on behalf of someone who doesn't even know that agent exists.

The good news is that the practices to solve it aren't new: dedicated identity, minimal permissions, and full traceability. What changes is the subject: we no longer only manage people and services, now also agents that act on our behalf. And if we can't say who asked for what, we don't have control, we have luck.

Source: The New Stack. Analysis and adaptation: ForgeNEX.