← Blog

Cisco-Astrix and the Rise of Identity-Aware AI Gateways

On May 4, 2026, SecurityWeek reported that Cisco moved to acquire Astrix Security for roughly $400M. The deal validates identity-aware AI traffic enforcement as a buying-center category. Non-human identities (NHIs) — API keys, OAuth tokens, agent identities — are the new entry point. This article walks through what the deal signals for the AI security stack, how NHI-platform-bolted-on approaches differ from inline policy enforcement at the LLM request boundary, and the RFP questions a CISO should ask before defaulting to a bundled offering.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Comparisons & Alternativesai-securityidentity-and-authorizationpolicy-enforcementai-governancearchitecturecybersecurity
Cisco-Astrix and the Rise of Identity-Aware AI Gateways

SecurityWeek reported on May 4, 2026 that Cisco announced its intent to acquire Astrix Security for roughly $400 million. The deal is the largest single transaction in the non-human identity (NHI) space to date. It follows Check Point's acquisition of Lakera, Palo Alto's acquisition of Protect AI, and a broader pattern of platform vendors absorbing point solutions that sit close to AI traffic. The signal is clear. Identity-aware AI gateway is now a buying-center category.

I want to walk through what the deal actually validates, the architectural distinction between platform-bolted-on NHI controls and inline policy enforcement at the LLM request boundary, and the RFP questions a CISO should be asking before defaulting to whatever the existing platform vendor offers as a bundle.

What Cisco-Astrix actually validates

Astrix's product covers the NHI inventory and posture management problem. API keys, OAuth tokens, service principals, and increasingly agent identities are issued without the lifecycle controls applied to human accounts. Astrix discovers the inventory, maps the connections, surfaces the over-privileged ones, and helps rotate or revoke. The product is a posture management layer.

The Cisco transaction bundles that posture management capability into a platform that also includes network, endpoint, and identity. For an enterprise already standardized on Cisco for network identity, the deal makes NHI a check-box on an existing vendor relationship.

Three signals follow from the price tag.

First, NHIs are the new entry point. A meaningful share of recent breaches involved a leaked API key, an unrotated OAuth token, or a service-account credential with standing privilege. The category was previously bolted onto IAM. Now it has its own platform line item.

Second, agent identities are part of the same conversation. The Astrix product roadmap explicitly covers AI agent identities. Cisco is paying for the option to extend the NHI posture model to agent fleets.

Third, every other platform vendor will respond. Expect Microsoft, Palo Alto, CrowdStrike, and Okta to announce comparable capabilities or acquisitions within two quarters.

The architectural distinction CISOs should hold onto

Posture management and inline enforcement are different functions. Conflating them is the most expensive mistake a CISO can make in the AI security stack.

Posture management surfaces standing risk

A posture management tool answers questions like: How many NHIs do we have? Which ones are over-privileged? Which ones have not been rotated in 365 days? Which ones can access this sensitive resource? The answer comes from inventory, configuration scanning, and graph traversal. The output is a list and a recommendation.

Posture management is forensic. It tells the security team what is wrong with the configuration. It does not stop a request in flight.

Inline enforcement evaluates a single request before the model is called

An inline enforcement layer sits on the AI request path. For every prompt that hits the LLM API, the enforcement layer evaluates who is asking, what the prompt contains, which model is being called, and what policy applies. The decision is made in tens of milliseconds. The request is allowed, blocked, or modified before it reaches the model.

Inline enforcement is preventive. It stops the request that should not have been made.

Both layers are necessary; they are not substitutes

A complete AI security architecture needs both. Posture management tells the security team that the customer-support service account has access to a payroll model it should not have access to. Inline enforcement stops the customer-support service account from actually calling the payroll model in production, regardless of whether the posture issue has been remediated yet.

The platform vendor bundle typically delivers posture. The inline enforcement layer is harder to retrofit and is usually the gap.

The post-authentication gap is what makes inline enforcement non-optional

Authentication answers who is calling. Authorization at the AI request layer answers what this caller is permitted to do with this specific prompt content right now. Most deployments answer the first and not the second.

Astrix-style posture management catches the configuration error that allowed the over-privileged credential to exist. The credential is still authenticated and still active until rotation completes. Between the moment posture identifies the risk and the moment the credential is rotated, every request made by that credential reaches the model. Inline enforcement at the request layer is the only control that bounds the blast radius during that window.

Meta's March 18 Sev-1 incident, where an internal AI agent exposed sensitive data to engineers who were fully authenticated but should not have been able to see it, is the canonical example. The engineers were authenticated. The credential was valid. No posture issue was visible. The exposure happened at the request layer, and that is the layer where it had to be stopped.

RFP questions a CISO should ask

A CISO evaluating whether to take the bundled offering should run the answers through these questions.

Where does the proposed control actually sit in the request path?

If the control sits at the IAM layer or the secrets-broker layer, it can revoke or rotate credentials. It cannot evaluate a specific prompt against a data-classification policy. The control is upstream of the model call.

If the control sits at the egress proxy or the SaaS-discovery layer, it can detect that a request was made to an LLM endpoint. It cannot read the encrypted prompt content without TLS interception and protocol-specific parsing.

The inline enforcement layer sits between the application or agent and the LLM API. It terminates TLS, parses the API payload, evaluates policy, and re-establishes the connection to the model. That position is the only one from which prompt-level enforcement is architecturally possible.

What is the per-decision audit primitive?

A defensible AI audit log records, per request, the identity, the prompt classification, the policy applied, and the decision. Posture management does not produce per-decision records. CloudTrail-style API logs do not capture prompts. If the proposed control cannot produce a signed per-decision record retained for the regulatory window, it is not a substitute for an audit-grade enforcement layer.

Can the control enforce on traffic to non-platform-vendor models?

A platform vendor's bundled AI control typically optimizes for the platform vendor's preferred models. AWS Bedrock Guardrails enforce on Bedrock. Azure Content Safety enforces on Azure OpenAI. A model-agnostic enforcement layer sits in front of any HTTP-based LLM endpoint regardless of vendor. Most enterprises run multi-provider AI today. The model-agnostic property is the difference between a single-vendor control and a control that covers the actual traffic.

What is the failure mode when the control is overloaded?

Fail-open enforcement defaults to allowing traffic when the control is overloaded or unreachable. Fail-closed enforcement defaults to blocking. For regulated environments, fail-closed is the only defensible posture. The RFP should require the vendor to commit, in writing, to fail-closed behavior on the AI request path.

Compliance posture

The EU AI Act's Article 12 logging obligations apply to deployers of high-risk AI systems. NIST is preparing the COSAiS overlays that will measure federal contractors and critical infrastructure operators against single-agent and multi-agent control models. Both regimes require evidence at the request layer. Posture management produces evidence at the configuration layer. The two regimes are not substitutes.

The deals consolidating NHI under platform vendors will accelerate the bundle conversation. CISOs should be ready to defend the architectural distinction between posture and enforcement in the procurement review, because the bundle will not.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline between authenticated users and agents and any HTTP-based LLM endpoint. The policy decision is made per request, in tens of milliseconds, against identity, prompt classification, model authorization, and organizational policy. The audit record is signed and written before the response returns. The enforcement layer is model-agnostic, fail-closed, and independent of any single platform vendor's roadmap.

If you are running multi-provider AI and want to see how inline enforcement complements a posture management layer rather than competing with it, book a demo today.

Frequently asked questions

Is Astrix going to compete with DeepInspect after the acquisition closes?

Posture management and inline enforcement are different functions. The Astrix product as it exists today catalogs and surfaces NHI configuration. DeepInspect enforces policy on the AI request path. The two functions are complementary in a complete AI security architecture.

Does an existing Cisco footprint mean we should default to the bundled AI control?

The existing relationship simplifies procurement. The architectural question is whether the bundled control sits at the layer where AI requests are actually evaluated. If the bundle covers the IAM and discovery layers, the inline enforcement layer is still a gap.

What does identity-aware mean at the AI request boundary?

Identity-aware means the enforcement decision uses identity context as a first-class input. The decision is not "is this prompt safe in the abstract?" but "is this prompt permitted for this authenticated principal acting in this role with this data classification right now?"

How does this differ from a network-layer DLP?

Network-layer DLP runs underneath the TLS encryption. It cannot inspect the prompt content unless TLS inspection is configured specifically for AI provider domains and the API payload is parsed. The inline enforcement layer terminates the AI traffic and operates on the actual prompt content with identity context attached.

What happens to the enforcement guarantee if the bundled posture management revokes a credential mid-request?

If credential revocation happens after the request has already reached the model, the response is on its way back. Inline enforcement on the response path can still redact or block, but the model has already been called. Preventing the call entirely requires the enforcement decision to happen at the request layer before the model is reached.