Platform
Identity for humans and AI
Human, AI, agent, application, service and tool identity in one model, so every action can be attributed to something and ultimately to someone.
Held centrally
Credentials
10
Held by agents
0
by construction
13 scoped grants are derived from them. A grant is short-lived and narrower than the credential it came from, and it never becomes the credential.
One model, six kinds of subject
Every action attributable to something. Every something resolvable to someone.
Those are two claims, and an estate needs both. The first fails when four services share a key. The second fails when the key's owner left last year. Neither is fixed by logging harder.
OpsAI does not replace your identity provider and holds no passwords. People arrive already authenticated. What OpsAI adds is the half that no identity provider covers: an identity for the WORKLOAD, issued per agent, attested rather than asserted, and joined to the person who accepted responsibility for it.
That join is the whole point. An identity that proves which agent called but stops there produces excellent logs and still cannot answer the only question an incident asks.
- People
- Authenticated by your existing identity provider. OpsAI does not replace it and does not hold a password — it consumes the assertion and attaches accountability to it.
- Agents
- An attested workload identity issued per agent, presented on every call, and resolvable to the team and the person who answers for it.
- Applications and services
- The same treatment as an agent. An internal tool with a model behind it is a workload, and it gets a workload identity rather than a service account.
- Tools and connections
- Identified by what they are permitted to do rather than by who is calling them, so a grant can be withdrawn from one caller without touching the others.
What resolves to what
Four hops from a signed credential to a name.
Read it upwards to audit and downwards to design. An action carries an attestation; the attestation names a workload; the workload sits in a team's namespace; the namespace has an accountable owner.
Attestation to accountability
every action, every timeAttested workload
The agent presents a platform-signed credential it did not mint itself.
Workload identity
A SPIFFE URI naming the namespace and the agent, issued once and never shared.
Team
The namespace resolves to the team that operates it.
Accountable person
A named human who accepted the system. The end of every chain.
The URI is composed from the agent's team, so it cannot drift from the registry on the agents page. Its attestation is mTLS client cert, chosen by what kind of workload it is rather than configured per agent.
Namespace support resolves to Support Ops, which answers to Priya Nair.
What a shared key cannot tell you.
Three questions, in the order an incident asks them. A shared credential fails all three, and it fails them silently — every log looks complete.
- Which workload called
- A key identifies itself, not its holder. Four services sharing one key produce one indistinguishable caller in every log downstream.
- Whether it was allowed to
- Whatever the key can do, the holder can do. Scope was fixed when the key was minted, by someone who was not thinking about this action.
- Who to call at 2am
- A key has a creator, not an owner. The creator has often changed team, and the key has outlived the reason it existed.
Where the secret lives
The agent never receives a credential. It receives a decision.
A credential is held once, centrally, and never distributed — not to an agent, and not to an enforcement point. What an agent gets is a short-lived grant narrower than the credential it derives from.
Credential vault
10 held · 13 derived grants| Credential | System | Kind | Scopes a grant may carry | Derived grants | Rotation |
|---|---|---|---|---|---|
| razorpay.live | RazorpayRazorpay | API key | refund:write · payment:read | 1 | 12/90d |
| razorpayx.payout | RazorpayXRazorpayX | OAuth client | payout:create | 1 | 51/60d |
| zohobooks.oauth | Zoho BooksZoho Books | OAuth client | journal:write | 1 | 34/90d |
| netsuite.tba | NetSuiteNetSuite | Token pair | vendor:write | 1 | 71/90d |
| salesforce.jwt | SalesforceSalesforce | JWT signing key | record:write | 2 | 22/180d |
| postgres.inventory | PostgresPostgres | DB role | stock:update | 1 | 27/30d |
| zendesk.api | ZendeskZendesk | API token | ticket:write | 3 | 8/90d |
| gmail.dwd | GmailGmail | Domain-wide delegation | mail:send | 2 | 44/60d |
| s3.warehouse | Amazon S3Amazon S3 | IAM role | dataset:export | — | 5/30d |
| box.legal | BoxBox | JWT app | doc:read | 1 | 96/180d |
Credentials held
10
centrally, never copied
Held by an agent
0
the whole design
Rotation due
2
past 80% of the window
Unused
1
no grant derives from it
IllustrativeThe OpsAI sample estate. Two credentials are deliberately past their rotation threshold — a vault where everything is always current would be a brochure.
Rotation without downtime and without a code change.
Nothing downstream holds the secret, so nothing downstream has to be redeployed to change it. That is the practical dividend of the inversion, and it is the reason rotation stops being an event that gets postponed.
01Issue
A second credential is created alongside the first.
02Dual accept
Both are valid. Every enforcement point takes either one.
03Cut over
New grants derive from the new credential only.
04Revoke
The old credential is destroyed at the source.
Where to start
Move one credential, and watch what stops needing it.
The first credential to move in is usually the one with the widest scope and the least clear owner. Once it is held centrally, every agent that used it becomes individually identifiable — which is the point at which the rest of the platform has something to decide about.