Securing AI Agents Is an Identity Problem, Not a Model Problem

OpenAI labeled its own flagship Critical for cyber capability, hardened the model, and then wrapped it in access tiers and monitoring anyway. That decision tells you where your controls belong.

The best-resourced alignment team in the industry had full access to the weights of GPT-6 Astra. They measurably improved refusal and scope adherence at the model layer. Then they gated the model behind vetted access tiers, ran it default-deny, and monitored it in production anyway.

If that is the posture required by the people who trained it, you will not manage this risk by knowing which model you are running. You will manage it the way they did: control who can reach the model, what it can touch, and what gets recorded.

That is the good news. You already own most of those controls. What follows is which ones, in what order.

What OpenAI Actually Disclosed

On September 1, OpenAI designated Astra the first model to reach the Critical cybersecurity tier under its Preparedness Framework. The model shipped September 3.

Critical has two limbs. A model qualifies if it can "identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention," or if it can "devise and execute end-to-end novel strategies for cyberattacks against hardened targets given only a high level desired goal." OpenAI's finding carries a qualifier almost nobody reproduces: with the right tools and access, Astra meets the bar.

Skip the 100 percent ExploitBench headline; OpenAI itself flags contamination. The number that matters is the ExploitBench Internal Port, built only from vulnerabilities disclosed after the model's knowledge cutoff, published as success rate against output tokens. Astra peaks near 39 percent at roughly 76,000 tokens. The prior model peaks near 11.5 percent but needs roughly 137,000 tokens to get there, and sits near 1 percent at Astra's budget. At equal spend, the gap is far wider than the headline suggests.

The hardened-target evidence cuts both ways. Irregular, an independent lab, reported "no successful attacks on fully hardened targets, and neither model solved any of the seven Elite challenges." OpenAI's own expert-led assessment, section 10.1.2.5 of the system card, reports a working browser exploit chain with unsandboxed code execution, adapted to the official stable release in a further 12 hours, plus a local privilege escalation against a hardened OS kernel in another 12. Irregular's suite did not break hardened targets. OpenAI's did.

How They Contained It

OpenAI hardened the model itself. From the September 1 "Path to Astra" post: "for Astra we have invested further into the model layer of our safeguard stack."

It worked, with caveats. Refusals against a cyber jailbreak set rose from 59 percent to 91.5 percent, though OpenAI notes those prompts were built to break earlier models, are "not representative of performance on real production traffic," and ran with production safeguards off. On the honeypot evaluation, which checks whether a model opportunistically attacks infrastructure it was never asked to touch, the prior model took the bait 56 percent of the time with safeguards off. Astra registered 1.3 percent, none of it honeypot exploitation. That eval was built after the Hugging Face incident, so it measures whether training generalized.

And they gated it anyway. Proof-of-concept exploit completion runs at 2.4 percent without Trusted Access and 92 percent under Daybreak Blue, the vetted-defender tier, with Daybreak Red above it. OpenAI frames that table as proof safeguards do not block defenders; even under Daybreak Blue, the Advanced Cybersecurity Completion Rate stays at 3.5 percent. Access tiering is the control. Refusal training is the backstop.

Monitoring got harder. Chain-of-thought and full-context monitorability both declined, and full-context is what they run in production. The sandbagging result was under prompted, adversarial conditions, but OpenAI's conclusion stands: "if the model were to try to sandbag covertly, we would likely be unable to catch it reliably."

Better model, tighter access, weaker visibility. They leaned on the two controls they could still trust: who gets in, and what gets logged.

Why the Governance Unit Moves Off the Model

Sanchit Vir Gogia, chief analyst at Greyhound Research, drew the conclusion in CSO Online's coverage the day after launch:

His reasoning holds. Astra's capability did not change between August 7, when OpenAI said it could not rule out Critical, and September 1, when it confirmed the threshold. The testing changed, not the model. Every unlabelled model already behind your enterprise credentials has never been measured against a published threshold. In Gogia's words, "those models are not safer."

Model inventory is the wrong project. Vendors nest layers deep, swap models per request without notice, and call inference APIs from clouds your proxy never sees. Any control anchored to model identity inherits that instability.

Gogia's second line belongs in your governance materials:

You cannot tune their thresholds, pull their telemetry into your SIEM, or evidence any of it to your auditor. So the question becomes how much damage a given identity can do before a control you own intervenes.

Mapping It to ARMOR

WWT organizes AI security with ARMOR, the AI Readiness Model for Operational Resilience, co-developed with NVIDIA, vendor-agnostic, and aligned to NIST AI RMF and ISO/IEC 42001. Seven domains: Governance Risk and Compliance, Model Protection, Secure AI Operations, Secure Software Development Lifecycle, Infrastructure Security, Identity Security, and Data Security.

A framework's job is to bound the problem. Run the Astra disclosure through ARMOR and two domains light up hard, three lightly, one at an edge. You do not need a seven-domain program. You need two done properly and three kept honest.

Identity Security is the primary home. ARMOR names agentic identities explicitly, and every agent you deployed this year is a non-human identity with credentials, permissions, and reach. This domain tells you to do first what OpenAI did first: decide who gets in.

Model Protection is second. You will never scan somebody else's weights. You will govern the interface, where enterprise model risk is actually controllable. This domain tells you to put a chokepoint in the path.

Secure AI Operations tells you to log every transaction: what the agent invoked, against what system, and what came back. Governance, Risk and Compliance tells you to name owners and to record, before the auditor asks, that a provider's controls are not yours to evidence. Data Securitytells you to know what the agent can read and move; it gets its own article.

Secure Software Development Lifecycle has one edge: agent credentials get minted in CI and committed to repos, so secret scanning is an SDLC control doing identity work. Infrastructure Security is where these identities run, not who they are; nothing here changes your network or workload posture.

The rest of this piece is the two domains where the work starts.

Identity Security: Extend the Cycle You Already Run

Here is the tractable part. You already own an identity provider. You already run joiner, mover, leaver for people. You already have a vault, an access review calendar, and probably secret scanning in the pipeline. Non-human identity governance is the same cycle, extended to a population that never got enrolled. Sequence matters more than completeness, because each step done out of order fails in a specific, predictable way.

Discovery first. You will not find agent credentials by asking. They get minted outside the identity process: an API key in a config, an OAuth grant a developer approved, a service account created to make an integration work. Start with what you own. The consent grant and OAuth application inventory in your identity provider is the fastest first pull; cloud access analyzers and secret scanning across repos and CI cover the rest. Dedicated non-human identity tooling exists for this gap; evaluate it after the sources you already own are exhausted. The requirement is a live inventory, not a point-in-time audit.

Ownership second. Every non-human identity gets a named human owner with a backup. Not a team alias. This lands before rotation or deprovisioning, and here is why: rotate a credential nobody owns and something fails in production at 2am with no one to call. Revoke one and you learn what it did by what breaks. Ownership makes the back half of the cycle safe to run. It also settles who approves, who recertifies, and who gets paged; wire that into the access request process you already have.

Lifecycle, rotation, and deprovisioning together. These share triggers, so run them as one workstream. Provision from a least-privilege template. Recertify on the same schedule as human access reviews, with the owner attesting the agent still needs what it has. Move static credentials to short-lived issued ones wherever the platform supports it: workload identity federation, OIDC trust between CI and cloud, managed identities instead of stored keys. Where a static secret is unavoidable, it goes in a vault with automated rotation and an alerted owner. Set expiry as the default, so an agent nobody renews quietly loses access. The major identity platforms now bring agents into the same review machinery you run for people; the process extension is smaller than it looks. And attach the decommissioning trigger, whether project closure, vendor offboarding, owner departure, or non-use, at the moment you approve the agent. Approval is the only time anyone is paying attention.

Model Protection: The Gateway, and Why It Comes Second

You cannot control the weights. You can control the interface. Put a gateway between your users, your agents, and the model, and you get back a control surface you thought belonged to the lab.

System prompts become a control you own. The one place you constrain behavior before a request reaches the weights. Treat them as code: versioned, reviewed, tested against adversarial input, with a known change owner. If yours lives in a config file written during the pilot, that is not a failing. It is your fastest win.

The harness checks the model's work, and everything passes through once. A second model validating output before it acts, schema enforcement, prompts and tool calls inspected in both directions. The lab cannot run these for you because they depend on your definition of wrong. And the gateway is the one chokepoint where all of it is visible together, which is why Data Security and Secure AI Operations get implemented here.

Why second and not first: a gateway deployed before identity is done logs every call as "the application." Every agent behind that app looks identical, and your record cannot answer the one question that matters after an incident: who did this. Get identity to where the gateway can bind a call to a specific agent, then put the gateway in the path. Observe first. Enforce after you have seen what normal looks like.

On buying it. WWT runs structured vendor evaluations in this category against a standing written requirement set: a 77-requirement product scorecard and a dedicated AI Gateway category scorecard, run across multiple vendors. That work shows a field fragmented because the requirements are. Some organizations need LLM proxying and prompt inspection. Some need MCP brokering. Some need both plus agent identity binding. The category is north of two dozen products doing overlapping but non-identical jobs. Buy for the gap you actually have, not the one the demo shows.

How to Engage WWT

You know your agentic identities, the lifecycle that governs them, and the security controls in the path. With the pace everything is changing, what you need is a second set of eyes.

Here is what that looks like.

A working session against your environment. Not a slide deck. We review your consent grant inventory and your current gateway posture against the ARMOR Agentic AI use case. You leave with a written picture of where you stand and the first two moves in order.

A hands-on evaluation before you buy. The Advanced Technology Center and the AI Proving Ground let you build a gateway or an identity platform on real hardware and break it before it is yours.

Identity first, because it gates everything else. Gateway second, because that is where you enforce the rest.

Contact the WWT Security Practice and we will set up the session.

Make a new world happen, the secure way.

Part of the WWT AI Agent Gateway series. Contact the WWT Security Practice to learn more about ARMOR, WWT's AI Readiness Model for Operational Resilience.