Atomicwork Joins Okta's Cross App Access Ecosystem to Bring Identity-Governed AI to the AI Workforce

Every tool call an AI agent makes needs a specific person's authority behind it, and there's usually no one standing by to grant that in the moment. Traditional identity infrastructure only ever had to solve either side of this problem; a service account carried an application's identity but had no idea who was behind it, while an interactive login carried a person's identity but needed them physically present to use it. An agent needs both at once, and neither one was built to provide AI access.

This is what breaks first when enterprises connect an AI agent to a real system. The workaround has always been the same: hand the agent a static API key or a standing service account, and hope someone remembers to scope it, rotate it, and revoke it once it's no longer needed.  

That's why Atomicwork is joining the Cross App Access (XAA) ecosystem. Not to slow AI adoption down, but to make sure it can move forward, custom governance builds, and unmanaged risk that stall most enterprise deployments today. This release hands governance back to IT and security teams — they now decide who gets the connection, what it can see, and when it goes away.

How it works in Atomicwork

Say a security engineer asks Claude what's happening with a specific ticket in Atomicwork. This is how it works: Claude asks Okta for proof of who's asking and for what — a signed, single-use assertion Okta calls the Identity Assertion Authorization Grant (ID-JAG)— good for minutes, not months. MCP has now formally adopted the same ID-JAG as an authorization extension. Atomicwork checks that assertion against its own resource authorization server, mints a scoped access token for that one exchange, and hands back only what that specific person is allowed to see.

No consent popup, because Okta already vouched for the person when they signed in that morning. There’s no standing user credential or per-user refresh token. The only long-lived secret is per requesting app and is held by the app, not the user.

And no separate connection for Claude to maintain on its own, since the whole exchange rides on the Okta relationship our customers already have.

We've joined Linear, Slack, Figma, and Datadog, among others, in building XAA-compliance so Atomicwork is reachable through any XAA-compliant requesting app, brokered entirely through Okta.

What an admin actually controls

This is what it looks like to give an application a slice of someone's authority instead of a standing grant of its own: building the resource-app side meant building to a specific, narrow set of levers — no more, no less — because that's what the protocol hands the IT admin:

Assignment: Who has this connection at all is an ordinary Okta app assignment. Add or remove a person, and Atomicwork access follows. There's no separate list to maintain on our end.

Read vs. write scope: Scopes get enforced on every single call, not just at login. An admin can grant an agent read-only access to requests and mean it, because there's no path for that agent to escalate itself to a write later in the session.

A single kill switch: Deactivate the connection in Okta, and the next token exchange fails. The only long-lived secret is the requesting app's own client secret, rotatable independently through Atomicwork.  

Compare that to what a normal OAuth connector does today:

This narrows risk without pretending to erase it. An agent compromised mid-session could still mint a fresh assertion for whatever that session already has open — Cross-App Access kills the forever-lived credential sitting in a vault, but it doesn't make a live compromise harmless. What it does buy is a blast radius bounded by active sessions and minutes, instead of however long it takes someone to notice a leaked key.

Real situations, real requests

Atomicwork already treats every employee's access as their own — their tickets, their approval chains, their audit trail. With XAA, employees don’t have to put in their API key to connect their favorite apps with Atomicwork. The reason we built this is a handful of very ordinary moments:

An employee asks, 'What's open on my plate right now?' Claude answers with that exact person's real tickets, scoped to what they’re allowed to see.

A new hire asks Claude to raise a request for access to Devin. The ticket lands in Atomicwork exactly as if they'd raised it there themselves — their name, their team, their approval chain.

Someone leaves the company. Okta removes them from the app assignment, and their very next call to Atomicwork simply fails. Nobody on the IT team has to remember to find and revoke a key.  

Security asks "what did this agent touch, and for whom?" Okta's logs answer the who, which app, and when for every exchange. Atomicwork's logs answer the rest: the specific tickets, requests, and tool calls that agent actually made on that person's behalf."

These aren't hypotheticals. They're why identity governance at Atomicwork has always meant treating every request as tied to a real identity — with its own scoped permissions and its own audit trail — rather than a workflow setting nobody reviews. This is the same discipline behind the access provisioning side of identity governance we've written about before. XAA gave us a standard way to extend it to how outside agents reach into us, instead of building a bespoke consent system ourselves.

What we're exploring next

Letting Claude act on someone's behalf through Okta XAA was the first place we solved this problem. Atomicwork already ships an AI Workforce: an Onboarding Manager that provisions a new hire's access across every connected app, an Incident Ops Manager that analyzes monitoring alerts to figure out what's actually happening at 2 a.m., and a Finance Ops Specialist that reaches into expense systems to close out a report. Each one carries its own role, its own scoped access, its own reason to reach into other systems on a user's behalf. Identity is what has to scale as that number grows, so we're working on extending the trust boundary you already have for your human employees to your AI Workforce. Governing them shouldn't need a separate playbook from governing employees, because an AI Coworker is a different kind of employee, not a different kind of problem.

‍