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 SSO & SCIM, the NHI roster, MCP auth, the WIF graph, key & residency posture and privileged logins. The capture predates the shipped SSO/SCIM backend, so its SSO/SCIM tab still shows that build’s honest "backend pending" notice — real screens, never fabricated data.
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, hardware step-up and SSO/SCIM are live; live-verified federation is 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.
- Shipped as read-only ingestion: roster connectors read the hyperscaler agent-identity registries — Microsoft Entra Agent ID, AWS Bedrock AgentCore and Google’s agent registry. Live-verified federation on the wire against them remains on the roadmap, and we do not claim it before it ships.
- Shipped for people: WebAuthn/FIDO2 and PIV/CAC smartcard step-up for privileged logins, enforced fail-closed — break-glass and critical approvals refuse below the hardware-verified AAL3 bar, and a session without a fresh ceremony reads as AAL1, never inflated (NIST SP 800-63B is a target standard; no conformance is claimed). Single-IdP OIDC/SAML SSO with managed, sealed configuration and SCIM provisioning of users and groups ship in the open build; per-tenant multi-IdP federation and enforced SSO policy are Enterprise.
Identity & NHI — questions
Does Olivares federate live with Entra Agent ID, AWS AgentCore or Google Agent Identity today?
Not as live-verified trust. Read-only connectors ingest those agent registries as roster snapshots, and the WIF graph itself is rendered from the federation rules you declare — it shows what you stated and what the rosters report, not a live-verified trust relationship on the wire. Live federation against those 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?
Yes. A privileged session steps up with WebAuthn/FIDO2 or a PIV/CAC smartcard certificate to the hardware-verified AAL3 bar of NIST SP 800-63B — a target standard; no NIST or FIPS conformance is claimed. The step-up is fail-closed: elevation expires after a short freshness window, a session without a verified ceremony reads as AAL1, and break-glass or critical approvals refuse to proceed below AAL3.
Do you ship SSO and SCIM provisioning?
Yes. The open build ships single-IdP OIDC and SAML with a managed, store-backed configuration — secrets sealed at rest, configuration writes gated behind an AAL3 step-up — plus SCIM provisioning for users and groups. What a directory group may confer stays an operator decision: role mappings are never writable from the IdP. Per-tenant multi-IdP federation and enforced SSO policy are Enterprise capabilities.
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.