Written by Jeremy Souffir Founder, JTS Tech Services
The short version: if your team has connected an AI agent to Slack, Notion, Jira, your CRM or your data warehouse in the last year, there is a very good chance that connection is held open by a static API key that somebody pasted into a settings box once, that has no expiry date, that no named person owns, and that would not show up in any offboarding checklist you run. On 24 August Okta made Agent SSO generally available. It lets an organisation register an AI agent as a first-class identity in the directory, apply the same access policies you apply to staff, and issue the agent a short-lived token when it needs to act inside another application on a user's behalf — rather than handing it a permanent key. It is included in core Okta SSO plans at no additional charge. That last detail is why this is worth twenty minutes of your week rather than a bookmark: for a large number of businesses this is not a purchase decision, it is a setting that is already paid for and currently switched off.
What actually shipped on 24 August?
Three things worth separating, because they are not the same thing and only one of them is free. The first is Agent SSO itself, now generally available and folded into the core single sign-on product. The second is the protocol underneath it, Cross App Access, which Okta describes as an open, vendor-neutral extension of OAuth that operates as an enterprise-managed authorization extension for the Model Context Protocol — in plainer terms, a standard way for the app an agent is calling to ask your identity provider whether this agent, acting for this person, is allowed to do this, right now. The third is a separate, paid subscription called Okta for AI Agents, which covers the wider governance work: lifecycle, ownership, the joiner-mover-leaver equivalent for non-human identities. Conflating those three is the easiest mistake to make reading the announcement, so here is the split as plainly as we can put it.
- Free, in core SSO plans: registering agents as identities, applying access policy to them centrally, and issuing short-lived tokens instead of static keys through Cross App Access.
- Open and not Okta's property: Cross App Access itself. It is an OAuth extension and it is designed to be implemented by other identity providers and other applications, which is the part that matters if Okta is not your vendor.
- Paid and separate: the deeper agent governance product. Ownership records, lifecycle management and the advanced controls sit in a different subscription, so "we turned on Agent SSO" and "our agents are governed" are not the same sentence.
- Not automatic anywhere: the application on the other end has to support the protocol too. Okta's own coverage names Anthropic's Claude, Asana, Atlassian, Canva, Datadog, Figma, Notion, Slack and Supabase among the integrations, which is a useful list precisely because it tells you the shape of the coverage rather than promising all of it.
Why does this matter if you have never heard of Cross App Access?
Because the failure it addresses is one you almost certainly have, and it has nothing to do with which identity vendor you use. Okta's own framing of the problem is unusually blunt for a press release: most agents reach enterprise data through static API keys, one-off OAuth grants and custom integrations built application by application, and as a result they operate as anonymous traffic with no owner, no policy and no audit trail. Read that as a description rather than as marketing and check it against your own stack. If an agent your team wired up in March started behaving oddly tomorrow, could you name the person accountable for it, see what it accessed last week, and cut its access in one place? For most businesses we look at, the honest answers are no, no, and no — you would be hunting through individual app settings hoping to find where the key was pasted.
Whose numbers these are
The headline statistic in this announcement is that only 34% of organisations apply the same identity and security controls to AI agents as they do to human employees. That comes from Okta's own AI Agents at Work 2026 research, published by a company that sells the fix, and you should read it with that in mind — we are quoting it because it is specific and checkable, not because it is neutral. The regional figures reported alongside it are worth more than the global one, because they measure the gap rather than the practice: in Asia Pacific, 91% of organisations report using AI agents while only 10% say they have a well-developed strategy for managing them, and in Australia 94% of executives believed they had visibility into AI use in their organisation while nearly 60% of workers reported using AI tools that had not been approved. That last pair is the number we would put in front of a board. It is not a statistic about agents. It is a statistic about the distance between what leadership believes is connected and what is actually connected.
Is this genuinely new, or identity vendors renaming what they had?
Partly the second, and it is fair to say so. Okta announced the broader Identity Security Fabric back in September 2025, with Cross App Access as one of its three pillars and backing from AWS, Google Cloud, Salesforce, Box and Automation Anywhere. So the idea is not a surprise and the protocol is not new. What changed on 24 August is the boring, decisive part: the piece went generally available and landed in the plan customers already pay for, rather than sitting in early access as a thing you could read about. That is usually the moment a security control stops being a conference slide and starts being something a mid-sized IT team can actually deploy on a Tuesday. Gartner's projection quoted around the original announcement — that by 2027 identity fabric immunity principles will prevent 85% of new attacks and cut the financial impact of breaches by 80% — is the kind of forecast we would not build a business case on, but the direction it points is the same one every incident we have written about this month points in.
The two conclusions that both get this wrong
The first wrong conclusion is "we are not an Okta shop, so this does not apply to us". It applies to you in the only way that costs money: the static keys your agents are holding right now are the same keys regardless of who sells you identity, and the protocol here is deliberately vendor-neutral, so the useful action is to ask your identity provider when they support Cross App Access and to inventory your agent credentials while you wait. The second wrong conclusion is the mirror image and it is the more expensive one: "we turned on Agent SSO, so agent security is handled". It is not. Short-lived tokens close the credential-theft problem and do nothing at all about an agent that is behaving exactly as authorised while being fed a malicious instruction by a document it was asked to read. Authentication answers who is asking. It has never answered whether what they are asking for is a good idea. Both readings make the same error in opposite directions: treating an access-layer control as either irrelevant or sufficient, when it is neither.
What would we actually do this week?
- Write down every agent that holds a credential. Not every AI tool — every agent or integration that has a key, token or OAuth grant into a system holding your data. This list almost never exists, it usually takes an afternoon, and it is the only artefact on this page that is valuable whether or not you ever adopt this protocol.
- For each one, name a human owner. A person, not a team inbox. If nobody will put their name against an agent's access, that is the finding, and it is a cheaper finding today than during an incident.
- Check whether Agent SSO is already in the plan you pay for. If you are an Okta SSO customer, this is included at no additional cost, which makes the question purely one of configuration time rather than budget. Confirm it against your own contract rather than taking a press release's word for it.
- If you are not, ask your identity provider one question in writing: what is your timeline for Cross App Access support? The answer, including a vague one, tells you how long you are going to be living with static keys and lets you plan around it.
- Set expiry on what you cannot yet replace. Where an agent still needs a long-lived key, give it one with the narrowest scope your app allows and a calendar date on it. A key with an expiry is a worse control than a short-lived token and a far better one than what most agents hold today.
- Add agents to your offboarding checklist. When a person leaves, the agents that acted on their behalf should be reviewed in the same pass. This is the single most common gap we find, and it survives every other control you put in.
- Do not let this replace the input-side work. Keep the human approval step on anything an agent does that spends money, sends external mail, or changes production, because that is the class of failure this control does not touch.
The genuinely encouraging part
For once, the fix arriving is cheaper than the problem, and it is arriving as a standard rather than as a product. That combination is rare and it is worth noticing. Identity for software that acts on your behalf could very easily have become another premium security tier that only large enterprises could justify, priced per agent, with mid-market businesses left holding pasted API keys for another three years. Shipping the core of it inside a plan customers already hold, on top of an OAuth extension that other vendors can implement, points the other way. It also means a growing business can plausibly end up with better agent hygiene than a much larger competitor, because the constraint here is an afternoon of inventory work and a configuration change rather than a procurement cycle. The businesses that will look reckless in twelve months are not the ones that could not afford this. They are the ones who never made the list.
Where we fit
We will be straight about the limits of what a post can do here: the inventory is the hard part, and it is hard for an unglamorous reason — the agents were connected by people doing their jobs, in different tools, at different times, without anyone recording it. That is exactly the work an AI Ops Automation Sprint is for. Retaining JTS means somebody goes through the stack and produces the list that does not currently exist: every agent, every credential, what it can reach, who owns it, and which ones are one prompt away from doing something expensive. We then wire the ones worth keeping through your identity layer properly, using short-lived tokens where your provider already supports them and scoped, dated credentials where it does not yet, and we put the human approval step back on the actions that genuinely need one. The output is not a policy document. It is a stack where you can answer the three questions that matter during an incident — who owns this agent, what did it touch, and how do I stop it — without opening nine admin panels. And we keep telling you which of these vendor announcements changes what you should do and which is a slide, which is most of the value in a year where identity, agents and access are all being rebuilt at once.
Sources
- Okta — Okta brings first-class identity to AI agents with Agent SSO (the primary announcement: general availability on 24 August 2026, Cross App Access as an open vendor-neutral OAuth extension operating as an enterprise-managed authorization extension for the Model Context Protocol, inclusion in core SSO plans at no additional cost, the separate paid Okta for AI Agents subscription, and the static-API-keys / anonymous-traffic framing of the problem)
- SecurityBrief — Okta launches Agent SSO to manage enterprise AI agent access (independent coverage, the Asia Pacific and Australia figures quoted above, and the list of applications with Cross App Access integrations including Claude, Asana, Atlassian, Canva, Datadog, Figma, Notion, Slack and Supabase)
- CSO Online — Okta introduces Identity Security Fabric to secure AI agents (background on the September 2025 announcement this grew out of, the three pillars, the vendors backing Cross App Access, and the Gartner projection on identity fabric principles)
- Okta — Single sign-on product page (what the core SSO plan is, for checking whether this is already inside what you pay for)
- JTS Tech Services — Agents arrive with ID and a wallet (the same idea pointed the other way: identity for agents arriving at your edge, rather than agents leaving your stack)
- JTS Tech Services — The AI supply-chain breach where the keys still work (why the static credential, not the compromised package, is usually the thing that is still open months later)
- JTS Tech Services — The AI notetaker nobody approved (how the agents in your stack got there without a procurement decision, which is why the inventory step is the hard one)
