AI Agents Need Identities, Not Just Instructions
2026-05-29 · 4 min read · Janaina Maia
The next agent design problem is not whether the agent can call a tool. It is whether the organisation can recognise the agent, limit what it can touch, and explain why the action was allowed.
Google announced an open-source MCP server for Chrome Enterprise security management, which lets AI agents connect directly to Chrome Enterprise APIs. In plain English, an administrator could ask an agent to investigate a browser security issue, review a policy rollout, or create a data loss prevention rule instead of clicking through admin screens manually. CIO Dive also reported that Snowflake is acquiring Natoma, a Model Context Protocol platform that adds governance and an identity layer for enterprise AI agents. These look like infrastructure stories, but I think they are product design stories.
When agents start acting inside enterprise systems, they need something closer to a work badge than a chat window. The badge should say what the agent is, who authorised it, which tools it can use, which data it can access, and where it must stop.
Agents need identity.
Most enterprise software was built around human users. A person signs in, gets a role, belongs to a group, and leaves an audit trail. Agents complicate that model because they may act on behalf of a person, a team, or a workflow. They may also move across tools faster than a human could reasonably inspect.
If the product treats the agent as invisible automation, accountability gets blurry. Was this action taken by Jana, by Jana's assistant, by a security workflow, or by a system policy? That distinction matters when the action changes access, sends data somewhere, modifies records, or triggers work for another team.
Design leaders should ask for agent identity as a first-class user experience. Not only an internal security control, but something visible enough that humans understand who or what is acting in the system.
MCP makes the connector problem visible.
Model Context Protocol, usually shortened to MCP, is a standard way for AI systems to connect to external tools and data. A simple analogy: if the AI model is the brain, MCP is one type of plug that lets the brain use approved tools without every team inventing a custom cable.
That is useful because agents become more capable when they can retrieve information, call APIs, and perform work. It is also risky because every connector expands the action surface. A connector is not just a technical integration. It is a permission decision.
This is why the Snowflake and Google moves matter. The market is starting to realise that agents need governed connectors, not improvised access. The boring parts, identity, scope, logs, policy, revocation, are becoming the product.
The interface should show the badge.
If an agent can act inside an enterprise workflow, I would want the product experience to make five things obvious:
- Identity: which agent is acting, and on whose behalf?
- Scope: which tools, records, policies, or environments can it touch?
- Authority: what level of action is pre-approved, and what needs human approval?
- Evidence: what sources or signals shaped the action?
- Revocation: how can a human pause, narrow, or remove access quickly?
That is not only a security admin screen. It is the trust layer of the agentic experience.
My take.
The future of agentic software will not be won only by better models. It will be won by products that make delegated authority understandable.
For enterprise teams, the design question is shifting from, "Can the agent do the task?" to, "Can the organisation safely recognise, constrain, review, and stop the agent?" That is a much more mature question.
An agent without identity is not a teammate. It is anonymous automation with a friendly tone. Before we give agents more tools, we need to give them visible badges.