Agent Identity: Give Every Agent Its Own Badge
Google gave agents their own inbox and directory entry. AWS moved permission checks to query time. Once an agent acts as a colleague, identity decides if it ships.
What blocks enterprise agents in 2026 is no longer how smart the model is. It is whose name is on the log line. In the past 48 hours, three cloud vendors pointed at the same answer: give the agent an identity of its own — its own mailbox, its own credentials, its own name in the audit trail.
Agents got badges this week
On October 8, Google announced a "universal agent for work" at its Gemini at Work event. The detail worth remembering isn't that it writes code. It's that it can turn itself into a coworker: a persistent agent with its own Workspace account, its own email address of the form @agents.company.com, its own calendar and Drive, and a line in the company directory. Colleagues can add it to a chat space, @-mention it, and watch it show up under its own name in document version history.
The governance model shipped in the same announcement. Every agent gets a cryptographically attested, least-privilege identity that is stamped into the logs it produces; when it calls an external system, that identity is propagated through OAuth; and every action it takes is written to an audit trail attributed to the agent rather than to a person. Agents execute inside an Agent Sandbox with its own network boundary, and all traffic passes through Agent Gateway, which Google describes as an AI network firewall. When a project-level spend cap trips, what gets paused is the agent — not the project.
AWS attacked the same problem from the other end. In a post published October 7, it split RAG permission checks into two stages: a pre-retrieval filter using the access control attributes already stored in the vector index, then a real-time call back to the authoritative source to confirm the requesting user still has access to each candidate document. Only verified passages reach the model's context. That fixes three specific failure modes — the AI system is not the source of truth for permissions, permissions copied during a sync go stale, and source systems keep changing how they express access. Mondelēz International, AWS notes, has deployed this across four regions and more than 35,000 employees.
China moved in the same week. On October 8, openJiuwen — built by Huawei's 2012 Labs, Huawei Cloud and a wider developer community — open-sourced an enterprise AgentOS that puts multi-tenant isolation, sandboxes, permission management and guardrails into the runtime base, exposing a unified agent gateway and five composable asset types (skills, connectors, plugins, experts, expert teams).
And Google Cloud's customer announcements the same day show how fast this runs in practice. Orange Spain let employees build more than 1,000 custom agents with low-code tools, reaching a near 100% license activity rate within 30 days. Sportswear brand On used multi-agent workflows to migrate 24 core services to the cloud, cutting migration time from three months to two weeks per service — 15 of them done entirely in-house, with under five minutes of planned downtime each, after an external vendor had quoted $500,000 for a fraction of the work.
Put the vendors side by side and the pattern is hard to miss:
| Vendor | Mechanism | The design choice |
|---|---|---|
| A separate Workspace account and verifiable identity per agent | Actions attributed to the agent; Agent Sandbox + Agent Gateway | |
| AWS | Keep the identity model, move the permission check | Verify access control lists against the authoritative source at query time |
| Microsoft | An agent user subtype in Entra Agent ID | No password, no privileged admin roles, a mandatory human sponsor |
(The Microsoft row follows The Daily Brief's comparison of the two identity models.)
A shared account is an incident wearing a convenience costume
All of that design work points back at an uncomfortable default: most enterprise agents today run on somebody's personal account.
It starts out feeling obvious — the account already exists, it has enough permissions, and the agent works the moment you wire it up. It fails in three places at once.
Audit stops working. Your agent places the order, changes the config, sends the notice — and the log says you did it. When something goes wrong there is no way to separate what you did, what you approved, and what it decided on its own. This is not a compliance team's pet peeve. Once an action cannot be attributed to a decision-maker, investigation, post-mortems, accountability and improvement all lose their handhold.
Permissions inflate. To let an agent finish real work, teams wire it into an account with enough access — usually an administrator's. Least privilege is abandoned at step one: an agent that should only read orders now holds every capability that account has. The blast radius of a prompt injection or a runaway action is measured by the account, not by the task.
Lifecycles get tangled. People change roles, leave, or have their access tightened, and the agent's visibility does not move with them. Revoking the agent, meanwhile, should not touch the human. Two lifecycles are welded together, and unpicking them by hand scales linearly with agent count — a count that is going from single digits to four digits in 2026.
This is a new version of an old security problem: the confused deputy, where a more privileged actor is tricked into doing work on behalf of a less privileged requester. The standard fix has been known for decades: give the deputy an identity of its own, so its actions represent itself and not you.
Microsoft writes that rule unusually bluntly in Entra Agent ID. An agent user account is a separate user subtype: it cannot hold a password or a passkey, it cannot be assigned privileged administrator roles, and every agent identity requires at least one human sponsor — a sponsorship that has to be maintained as people move, because someone has to take over when a sponsor leaves.
Four questions, and the fourth one isn't a platform feature
Google compressed the whole agenda into four questions: who is the agent, what may it do, what did it do, and what must it never touch.
| Question | Who has to answer | What it becomes |
|---|---|---|
| Who is the agent | Platform + security admin | Independent credentials, identity propagated over OAuth, verifiable claims |
| What may it do | Security admin + business owner | Role-based scope, least privilege, per-project limits |
| What did it do | Runtime base | An action ledger under the agent's own name |
| What must it never touch | Data and business teams | Data scope, field-level sensitivity, card-level authorization |
The first three are becoming product features, and the answers are converging: an independent identity, least privilege, an action ledger. They share one premise — that an agent is a manageable entity. That premise only became a genuine default in the second half of 2026, and it is what turns the action ledger we wrote about earlier from a recommendation into something that ships in the box.
The fourth question is different. "Never touch" is not a decision a platform can make for you — it is a property of your data. The same Agent Gateway policy means "never touch the payroll table" at one company and "never touch last month's reconciliation detail" at another. A platform can see traffic. It cannot know which column belongs to whom, which metric definition is the real one, or which table quietly mixes two business domains. We argued where the guardrail has to sit before, and the conclusion holds: the closer to the data, the harder it is to bypass.
So the fourth question has to be answered in the data layer: which entities exist, which fields are hidden by default, and who is allowed to see the sensitive ones. Skip that, and a perfect answer to the first three still leaves you with a permission framework and nothing inside it.
Move the unit of authorization into the data card
Once agents go from ten to a thousand — Orange Spain's 1,000+ and openJiuwen's composable asset model both point there — configuring permissions by hand stops working. Scale has exactly one fix: change the unit of authorization to something meaningful.
- Too coarse (one database account) and the blast radius of a leak is the entire account.
- Too fine (per-field grants) and nobody can maintain it; it drifts within six months.
- The middle option — granting by table or schema — looks reasonable until you notice that most tables mix public and sensitive columns, forcing the strictest possible rule and taking usability down with it.
The unit that works is the data card: one card per business entity (order, refund, customer, asset), carrying three things at once — its meaning (what each field is, how the metric is defined), its scope (which rows belong to this domain), and its sensitivity (which fields are hidden, masked or open by default). Granting an agent access stops being "issue it an account" and becomes "hand it these cards."
Two things follow. It becomes enumerable — what you gave the agent is a finite list a security team can review, an auditor can trace, and one click can roll back. And it becomes reusable — cards are an asset, so the next agent inherits the same scope definition instead of a copy of someone's job permissions.
One more note on the semantic layer, which is really part of the agent's identity. If "revenue" has three definitions in three departments, the same agent will see three different worlds depending on who is asking, and the log will record a single number. Making every agent start from one definition, and making every agent speak with its own credentials, are two faces of the same discipline — which is the whole point of a semantic layer.
Here is the short version you can take to a review. None of it is complicated; what is hard is that every line needs an owner.
- Its own credentials — one service account per agent, never a personal token, so revocation means deleting one thing
- A named human sponsor — kept current as people move, instead of set and forgotten
- Agent-attributed audit — actions written under the agent's name, plus a record of who authorized that agent
- Card-level authorization — read scope expressed as a list of data cards, with field sensitivity enforced before retrieval
- Human approval on consequential writes — pricing, deletion, payment, publishing, outbound messages, each with a rollback path
- Spend caps and circuit breakers — pause the agent rather than the project, because cost is a safety control too
What to settle before the next hire isn't human
The real change this week isn't a stronger model. It's that the agent failure mode moved from saying the wrong thing to doing the wrong thing — and organizations now have to assign identity, permission and accountability to something that isn't a person.
Three questions are worth settling before the year ends: whose account is your agent using right now; whose name is on its actions in the log; and — if a new agent starts work tomorrow, can you produce a list of what it must never touch?
In OntiCards, that list is the data card itself: cards carry meaning and scope, the ontology layer keeps one word meaning one thing across the organization, the skill library declares risk level and fallback behaviour, and the agent ecosystem can only act inside the boundary those three draw. If you want to see what this permission model looks like in practice, start with the product page; if you have already run an agent pilot and are wrestling with where permissions should stop, write to hello@onticards.com.
