On 8 October, Google introduced a Gemini agent that gets its own email address. At its Gemini at Work event, Google described a "universal agent for work" whose persistent coworker agents receive their own Workspace identity, a calendar and storage, and act under that identity rather than the user's. It will connect to Workspace and Microsoft 365 as well as Slack and Jira, and to any MCP server inside or outside a company's network. Leave the product aside for a moment. The question it raises about AI agent identity is one every enterprise will face within a year: what is an agent's identity, and who answers for it?
Why AI agent identity is now an architecture decision
Until recently, most AI tools borrowed a person's credentials. The assistant read your email because it was you, as far as the system could tell. That works at pilot scale and breaks the moment agents act on their own, in parallel and across systems.
Google's design answers part of that. According to Futurum's coverage, agent identity is cryptographically attested, permissions propagate through OAuth and audit trails attribute actions to the agent. TechCrunch reported that the audit trail is attributed to the agent rather than a person. Futurum's analyst called agent identity a baseline requirement, giving security teams a clear line between human and agent actions.
I think that reading is right. What it leaves open is more interesting.
What AI agent identity actually has to answer
Identity is only useful if it answers questions people will ask later. Who created this agent? Who is accountable for what it did? What was it permitted to touch and for how long? Can it be paused, and by whom?
A named human owner is the part many miss. In a CIO Dive piece on 12 October, security vendor Bedrock Data's George Gerchow put it plainly: treat every agent as a new identity with a named human owner. That is advice rather than data, but it is hard to argue with. An agent with an email address and nobody responsible for it is an orphaned account waiting to happen.
The cross-vendor problem
Here is where it gets awkward. Google's identity model covers Google's agents. Your organisation will run agents from several vendors, plus some you build. Each will arrive with its own identity scheme, its own logs and its own idea of permissions. An enterprise architect looking at that picture sees a registry problem, not a product problem.
There is also a live debate about where guardrails should sit. In an 11 October VentureBeat piece, Workday's CTO argued that policy enforcement belongs close to the system of record, not in external gateways or prompts. It is a vendor's opinion, and Workday sells the platform it recommends, so weigh it accordingly. The architectural point still stands: identity and policy need to be enforced where the data and the transactions live.
A composite scenario
A finance team deploys an agent to chase supplier invoice queries. It gets its own identity, reads invoices and, over time, is also granted rights to update payment details because that saves a step. Months later a payment goes to the wrong account. The audit trail shows the agent acted. It does not show who approved widening its permissions, because nobody recorded that decision. Identity told the team what happened. Architecture should have told them why it was allowed.
What to be careful about
Google's announcements came with few general availability dates and no pricing, and Futurum noted that customer results mostly reflect earlier Gemini Enterprise deployments rather than the new agent. Treat the controls as direction of travel until they are in production.
What This Means for Your Organisation
What we see across organisations is that identity for agents gets decided by whichever team deploys the first one. By the fifth, there is no consistent answer. A small piece of reference architecture settles most of it: a register of every agent, a named owner for each, a defined permission scope, an audit location and a pause mechanism. That is dull work. It is also the work that makes everything else governable.
Key Takeaways
- AI agent identity is shifting from borrowed human credentials to distinct agent identities with their own audit trails.
- Each agent needs a named human owner and a recorded history of permission changes, not only a log of its actions.
- A single vendor's identity model will not cover a multi-vendor estate, so the register needs to be yours.
- Google's controls are announced rather than proven, with availability and pricing still unclear.
How Trusenta Can Help
- Enterprise Architecture in the AI Era helps you design the agent register, identity patterns and enforcement points across your estate.
- AI Governance records each agent, its owner, permissions and decisions in one governed place.
- Fractional Enterprise Architect gives you senior architecture capacity to set the standard before agents multiply.
Conclusion
Giving an agent a name is the easy part. Deciding who answers for it, what it may touch and how you would switch it off is where the architecture really sits, and it is worth settling before the number of agents makes the question urgent.
