Product · Identity & NHI
Give every agent its own identity — and know when it doesn’t
A shared service account makes "which agent did this?" unanswerable. Olivares binds an agent to a non-human identity, mints a dedicated per-agent NHI, and surfaces the agents that are sharing one — the difference between attributing access firmly and only approximately. An identity it cannot resolve is never quietly treated as a real one.
In the product
The identity console
A genuine screenshot, example data. Tabs for the NHI roster, MCP auth, the WIF graph, key & residency posture and privileged logins. The SSO/SCIM tab is candid about its own seam: the backend endpoint is not live yet, so it shows nothing rather than inventing it.
What you govern
From a shared account to a per-agent identity
Identity is the axis the access map attributes on. A dedicated NHI per agent turns "approximately" into "firmly"; everything below is honest about how far it can get.
Bind or mint an NHI
Bind an agent to an existing non-human identity, or mint a dedicated per-agent NHI. A dedicated NHI is what lets the access map attribute access firmly to one agent — not approximately to a pool.
Shared-identity finding
When more than one agent rides the same account, per-agent attribution is genuinely ambiguous. Olivares surfaces that as a finding and says so — it does not split the difference and pretend it knows which agent acted.
Read-only WIF graph
A workload-identity-federation graph maps your per-agent identities to your IdP. It is rendered read-only from the federation rules you declare — a view of what you stated, not a live verification of the trust on the wire.
The honest unknown
An identity Olivares cannot resolve is drawn as unknown and flagged — never silently promoted to a named NHI. No identity signal means no attribution, stated plainly.
How it works
Federating a per-agent identity to your IdP
Each agent gets a per-agent identity — a SPIFFE/WIF credential — that federates to your identity provider. An agent with no resolvable identity is not folded into a real one: it is drawn apart and flagged.
What’s real
NHI binding and the WIF graph are live; live federation and AAL3 step-up are not
We are precise about this, because the difference is the whole point of an identity surface:
- Live: binding an agent to an NHI, minting a dedicated per-agent NHI, the shared-identity finding, and the read-only WIF graph. The graph reflects the federation rules you declare — it is not a live-verified picture of federation on the wire.
- Roadmap: live federation against the GA hyperscaler agent-identity registries — Microsoft Entra Agent ID, AWS AgentCore, Google Agent Identity. We render declared rules today and do not claim live verification before it ships.
- Not built: WebAuthn AAL3 / PIV-CAC step-up. It is not implemented and fails closed to AAL1 today — we say AAL1, not the assurance level we have not earned. Some live identity sources (LDAP, IdP, secret managers) and SCIM Groups are not yet wired, and the SSO/SCIM tab is candid about it: backend pending, nothing to show, never fabricated.
Identity & NHI — questions
Does Olivares federate live with Entra Agent ID, AWS AgentCore or Google Agent Identity today?
No — not live. The WIF graph is read-only and rendered from the federation rules you declare, so it shows what you stated, not a live-verified trust relationship on the wire. Live federation against those GA hyperscaler agent-identity registries is on the roadmap, and we do not claim it before it ships.
Two agents share one service account. Which one does Olivares say acted?
Neither, firmly. A shared identity makes per-agent attribution genuinely ambiguous, so Olivares raises a shared-identity finding and attributes access only approximately — it will not fabricate certainty about which agent acted. Mint a dedicated per-agent NHI and the access map can then attribute that agent firmly.
Do you support WebAuthn AAL3 or PIV-CAC step-up for privileged logins?
Not yet. AAL3 step-up via WebAuthn or PIV-CAC is not built; today the path fails closed to AAL1, and that is exactly how we label it — we do not display an assurance level we have not earned. The privileged-login tab shows what is actually enforced now.
Why is the SSO/SCIM tab empty?
Because the backend endpoint for it is not live yet, so there is genuinely nothing to show — and the product says so rather than seeding it with plausible-looking data. The same goes for live identity sources like LDAP, IdP and secret managers, and SCIM Groups: not yet wired, shown honest-empty.
Give your agents identities you can attribute
Deploy Olivares on your own infrastructure, mint a dedicated NHI per agent, and turn "approximately" into "firmly" on your access map.