There is a specific kind of agent that keeps me up at night. Not the one drafting emails or summarising a PDF. The one you hand the keys to your identity provider.
People are already building them. An agent that onboards a new hire in Okta. One that provisions a service principal in Entra. One that spins up an IAM role so a pipeline can run. These are useful, and they are exactly the agents you least want acting unsupervised, because the actions they take are the actions that decide who can do what across your whole company.
Here is the uncomfortable part. An Okta API token is unscoped. It inherits the full permissions of the admin who created it, so an agent holding one can do anything that admin can. Point five agents at the same token and they are indistinguishable. When one of them grants someone a Super Admin role at 3am, your audit log says the token did it. It cannot say which agent, or on whose authority, or whether that was even supposed to happen.
That gap is the whole problem, and it is the same across the stack: Okta, Microsoft Entra, AWS IAM. The vendor secures the connection. Nobody proves which agent, acting for which human, made which change.
What we shipped
In this release, Vorim sits in front of three of them. When an agent goes to write to Okta, Entra, or AWS, the call passes through Vorim first. We check that the acting agent is who it claims to be and holds a real, scoped grant for that action. We record it, signed, so the change is attributable to a specific agent identity forever, not to a shared token.
And for the operations that actually matter, we stop and ask a human.
Not every write. Creating a user or assigning an app is an ordinary write, and it passes if the agent is allowed. But the operations that grant standing power or mint a lasting credential always escalate to a named admin, who has to approve before anything happens. On Okta that is granting an admin role and minting an API token. On Entra it is assigning a directory role, adding a client secret to an app, and granting a tenant-wide app-role assignment. On AWS it is CreateAccessKey, the one call that mints a long-lived static credential that never expires, plus the role and policy changes that quietly escalate privilege.
The agent can propose those. A person authorises them. That is the difference between an agent you demo and an agent you actually let near production access.
An honest note on what this is, and isn't
We guard the stable, real admin APIs that are free to use today: the Okta Management API, Microsoft Graph v1.0, and AWS IAM and STS. We deliberately do not claim to integrate with the shiny agent-identity products the vendors announced this year. Microsoft's Entra Agent ID create API is still on the Graph beta channel, which Microsoft itself marks as not for production. Okta for AI Agents has no separate self-serve API yet. AWS AgentCore Identity needs a billing-enabled Bedrock account. Those are real and worth watching, and we will build on them when they reach a stable, general release. Listing an integration with something you cannot actually ship against is exactly the kind of thing we would rather not do.
How it looks
You never hand us your Okta or AWS credentials. You pass the call you were going to make anyway, and we wrap it.
import createVorim from '@vorim/sdk';
import { createVorimOkta } from '@vorim/sdk/integrations/okta';
const vorim = createVorim({ apiKey: process.env.VORIM_API_KEY });
const okta = createVorimOkta(vorim, {
agentId: 'agid_provisioner',
orgUrl: 'https://acme.okta.com',
adminId: 'security_lead', // who approves privileged ops
});
// Ordinary write: passes if the agent is allowed, and is signed.
await okta.guardedCreateUser(
{ targetId: 'newhire@acme.com' },
() => oktaClient.userApi.createUser({ body }),
);
// Privileged: this escalates to security_lead and waits for approval
// before the role is ever granted. The agent cannot do it alone.
await okta.guardedGrantRole(
{ targetId: 'user_9', role: 'SUPER_ADMIN' },
() => oktaClient.assignRole({ userId: 'user_9', body }),
);Entra and AWS work the same way, with createVorimEntra and createVorimAwsIam. Same in Python, with pip install vorim.
On compliance, we say this carefully, because it is easy to overclaim. A signed, attributable record of every identity change is strong evidence for SOC 2 logical-access and change-monitoring controls. No framework actually requires cryptographic signatures on your logs. Signing is a stronger-than-required way to make those records tamper-evident and provably attributable to one agent. That is the point of it, not a checkbox someone made us tick.
Where this sits
This is the same idea as everything else we build, pointed at the highest-privilege surface in your company. An agent acts, we prove which agent it was and that it was allowed, and the truly dangerous moves need a human. The difference here is the blast radius. When the thing an agent can grant is admin access to your entire directory, "which agent did this, and who approved it" stops being a nice-to-have.
The three integrations are live in the SDK today.
Ready to build with AI agents?
See how Vorim gives your agents identity, permissions, and a signed audit trail. Book a walkthrough with our team.