In April a team sets up an AI agent to run overnight jobs that read from two data stores. The agent runs under a service principal created for it, with a role that grants read access, and that grant goes through the usual approval.
In July one of the jobs starts failing. An engineer adds write access on one of the data stores in the cloud console to get it running again. The fix works, and the extra permission stays. No request was filed, so the next IGA sync shows the new permission with nothing to say why it exists.
In August the person who set up the agent moves to another team, and the reasons behind the April setup and the July fix go with them. The account executing as the AI agent keeps running with read access to two data stores, write access to one, and an owner who no longer works on it.
In October a behavioral alert arrives in your detection and response tooling naming the account. The analyst has to work out what it is, what it can reach, who approved that reach, and who owns it. Each change was logged somewhere, in a cloud console, a ticket or an HR system, and none of it arrives with the alert.
If someone asks why that account has write access, there is no single place to look. The access request system never saw the July change, and the SOC had no reason to flag it. That question falls between the two halves of identity security.
The middle of identity
Identity security has two sides. On the left, Active Directory or your IdP, IGA and PAM declare intent: who should have access. On the right, SIEM, XDR and ITDR detect effect: what an account did, and whether it looks wrong. The April grant went through the left, and the October alert came from the right. The July write access landed in the space between them.
That middle is where the context layer belongs. It is an identity system of record: every change to every account, human, non-human and AI agent, kept in order, with who made each change wherever the source system recorded it. The memory window is what we at Hydden call the time period you can look back across to explain why any account has the access it has. Without that record, it often reaches only as far as today's configuration. The system of record fills in that missing information for every account it collects. The agent's history from April to October is one example of what it holds.
What each side sees
Each side holds part of an account's story, and the system of record holds the history that connects them. The left side sees intent. Most of its tools collect snapshots on a schedule and overwrite what they knew last time, so the events that changed an account's access have to be worked out on the fly.
The right side sees use. SOC teams apply behavioral analysis to AI agent and other non-human identity activity, and an account executing as an AI agent can hold broad access for months while doing only permitted things. Behavioral analysis flags use that looks wrong, not when access was granted, how it changed, or who owns the account. That is detection without the record behind it.
So the October analyst rebuilds the story by hand from the cloud console, Active Directory or your IdP, and the ticket queue. That can take days, and the person who set up the agent may no longer be around to ask.
What Hydden records in the middle
Hydden is the identity system of record that provides this context layer. It collects from the systems you connect, including ones that never kept a useful change log of their own, and keeps a continuous history of every identity, human, non-human and AI agent. When a collection differs from the last one, that difference becomes a timestamped event: a credential created, a role attached, an entitlement added. Where the source recorded who made the change, that travels too, so each change carries its author and its place in the account's history.
Every AI agent runs under an account, such as a dedicated service principal, a shared service account, or a human user's account through delegation, and that account holds the privilege. The account's record shows the account executing as the agent, the human owner Hydden's rules identify for that account, what that account can reach through which chain of roles and groups, and how that reach changed over time.
That record serves both sides. With Hydden's SIEM integration, the October alert arrives with its history: the analyst sees, inside the case, the April grant, the July write access and who added it, and that the person who owned it left in August. The left side sees the changes it did not make, like the July write access, with who made them, while there is still time to question them. The same history is there for any account an alert names. Enforcement still runs through the systems of authority the company owns. Hydden holds the record.
Why the middle needs a system of record
Identity teams want automation and AI agents to take on work like preparing reviews and cleaning up stale access. Those agents will need to know why access exists, and that takes the grant history. We'll cover that in a later post.
The context layer is that system of record: one record, collected across the systems you connect, that keeps every change to every account instead of overwriting it and stays in place after the person who built an agent moves on. With it, the October investigation starts with the account's history in front of the analyst, and the identity team had months to question the July change or the owner who left before any alert fired.
To see the grant history of every human, non-human and AI agent account in one system of record your SOC and identity team can both use, schedule a demo.
Frequently asked questions
What is the identity context layer?
It is the identity system of record for every human, non-human and AI agent account. For each account it holds when access was granted, how it changed, who changed it, and who owned the account at each point.
What is the memory window?
The time period you can look back across to explain why any account has the access it has. It stays short when the reasons behind setups, fixes and new credentials stay with the person who made them.
Is Hydden a SIEM for identity?
No. The SIEM keeps running detection and cases. Hydden keeps the identity system of record those detections draw on: every change to every account, who made it where the source recorded that, and the owner Hydden's rules identify.