Inside the Identity Agent
Most of the Things Touching Your Data Aren't People.
Service accounts and agents now outnumber your staff many times over. Meet the agent that anchors who's who to your identity provider - and ties every action to a real identity.
"Who is this?" and "who did this?"
Two questions quietly haunt every data team, and neither has a good answer. Who is this? - the same person shows up as six different usernames across Okta, Snowflake, Slack, and warehouse RBAC, and access reviews become a reconciliation nightmare. And who did this? - a destructive action lands under a shared service login and the audit chain dead-ends; proving who really ran it becomes a multi-day forensic hunt.
Underneath both is a shift most identity tooling never planned for. It was built for employees you onboard a few hundred at a time - but machine and agent identities now outnumber humans by orders of magnitude (industry reports put the ratio anywhere from 50-to-1 to over 100-to-1), they spawn each other automatically, and the offboarded employee's service tokens keep working months later. The breach won't come through a person.
What our Identity Agent actually does
The Identity Agent treats every actor - human, service account, or autonomous agent - as a first-class identity that can be resolved, attributed, and reviewed.
Your identity provider stays the source of truth for who people are, by design: the agent reads Okta or Entra ID, and every person signs in through it, so who is this? has one answer instead of six disjoint accounts. It ties every action Data Workers takes, and every approval, to the person who signed in or the agent that acted on their behalf, and writes it to the audit trail, so who did this? stops being a forensic project. It keeps every grant Data Workers records in one ledger with its requester, approver, purpose, and expiry, surfaces the grants that have outlived their purpose, and routes them to the owner to revoke. And it gives the machine-identity sprawl the same first-class treatment as people - who they are, what they can reach, whether anyone still owns them. That ledger and audit trail are what let the governance and security agents answer who was given this sensitive asset? in one motion instead of three exports.
The shape of the win is a question becoming answerable. "Who was granted this, and is any of it stale?" turns from a quarter-long, multi-export scramble into a query - because every grant and every action Data Workers handles ties back to one identity you can trace.
Here's the reframe: identity isn't a directory of people - it's the answer to "who did this?" for everything that touches your data, and most of those things aren't people anymore. That's why it sits inside the swarm rather than off to the side: its ledger and attribution feed the governance agent that proposes the revoke for the stale grant, the security agent that scores the exposure, and the audit that has to answer on demand.
A few of the agent's capabilities
The Identity Agent ships with a deep toolkit. A sampling of what it can do:
| Capability | What it does |
|---|---|
| IdP-anchored identity | Reads Okta or Entra ID as the source of truth for who each person is, by design. |
| Action attribution | Ties any action - human, service account, or agent - back to a real, resolved identity for the audit trail. |
| Grant ledger | Records every grant Data Workers handles with its requester, approver, purpose, and expiry, for governance and security to act on. |
| Stale-grant surfacing | Flags grants past their expiry or unused since they were granted, and routes them to the owner to revoke. |
| Entitlement reports | Lists everything a person or service account was granted through Data Workers, when, and how recently it was used. |
| Non-human identity coverage | Treats service accounts and agents as first-class identities, not blind spots, as they outnumber humans. |
| Revocation on request | Takes a revoke with its reason, applies it after approval on Unity Catalog, and proposes it to the owner on other platforms. |
| Agent-action provenance | Records which agent acted, on whose behalf, and under what purpose - readable from the audit chain. |
| Access-review support | Hands reviewers the "who was granted this, and when?" record from the ledger and audit trail, so audit prep starts from records instead of exports. |
| Swarm hand-off | Feeds resolved identity and access context to the governance, security, and catalog agents in one motion. |
…and these are just a few of many - the agent carries dozens more autonomy skills, with new ones added continuously.
How this is different from an identity suite
The incumbents own pieces of this, not the whole.
Okta and SailPoint dominate identity governance for human access certification, but they operate at the app-provisioning tier, not the data-grant tier - they tell you a person is in a group, not which warehouse columns that resolves to or who really ran a query under a shared service account. CyberArk and the secrets-manager camp handle machine-credential storage and rotation - CyberArk itself published the 82-to-1 non-human-to-human ratio - but a vault stores and rotates secrets; it doesn't reconcile one human's six usernames or attribute an agent's action to a purpose. Immuta has moved closest to our space, with agent-as-first-class-identity access that auto-revokes, enforced at the warehouse tier - genuinely strong at the warehouse tier, where Data Workers works through approved grants and a recorded ledger instead.
Where the Identity Agent differs is altitude and integration: it isn't a standalone governance suite or a vault - it's the identity and attribution layer inside a swarm that already maps your data estate, feeding governance, security, and audit in one motion instead of another console to reconcile by hand.
The takeaway
Identity stayed a human problem long after the actors stopped being mostly human - so the service accounts multiplied, the agents got standing credentials, and "who did this?" quietly became unanswerable. An agent that anchors every actor to your identity provider, attributes every action, and surfaces the stale grants is what makes the question answerable again. You can't secure, audit, or trust what you can't name - and most of what's touching your data is currently unnamed.
See it on your own stack
Point the agent at your identity providers and warehouse - and watch it tie every action it handles to a real identity, keep every grant in one ledger with its expiry, and surface the stale grants nobody remembered. Book a demo to see it on your stack.