On August 25, 2026, Cisco announced that AI Defense will run on Armada infrastructure — bringing AI red-teaming and runtime protection to workloads in sovereign clouds, enterprise data centers, and edge environments. Cisco describes it as protection “enforced where workloads run and governed consistently across cloud, sovereign, and edge environments,” with “centrally managed policies, visibility, and reporting across supported distributed deployments.”

This is a serious piece of engineering from a company with real distribution, real threat intelligence, and real placement in the network. It is also a signal about where the category is going. For anyone building or buying AI control infrastructure, the useful response is not to argue about it. It is to ask what it makes ordinary, and what it leaves open.

The short version

Running enforcement close to the workload is becoming table stakes. It solves placement — latency, data residency, jurisdictional control. What placement does not settle is authority: whether a specific consequential action was permitted, under which exact policy, and whether anyone outside the vendor can verify that afterward. Those are separable problems, and the second one is where the next round of differentiation happens.

The market is converging on runtime

Three years ago, “AI governance” mostly meant documentation: model inventories, risk assessments, framework mappings. The enforcement story was a policy PDF and a review board. That has changed quickly, and the Cisco/Armada announcement is a good marker of how far.

Look at what is now table stakes across the serious vendors: inspection of prompts and responses in the live path; agent and tool-call governance; MCP-aware inspection; enforcement points that sit next to the workload rather than in a distant SaaS; central policy management with distributed application. Cisco's February 2026 AI Defense expansion added an MCP Catalog and real-time agentic guardrails designed to catch “poisoned tools or prompts designed to trigger unauthorized tool use.” The August announcement pushes the same enforcement onto sovereign and edge infrastructure.

When a capability shows up in a Cisco press release, it stops being a differentiator and starts being a checkbox. “We enforce at runtime” is now roughly as distinguishing as “we support SSO.” That is good for buyers. It also means the interesting questions have moved.

The control question changes shape

For most of the last decade, the security question about a request was:

Was this traffic inspected, and did anything malicious get through?

That is the right question for a threat. It is not sufficient for a consequential action. When an AI agent moves money, denies a loan, adjusts a clinical pathway, or writes to a system of record, the questions a regulator, a model-risk function, or a chief audit executive will ask are different:

These are authorization questions, not detection questions. A system can be excellent at the first and structurally silent on the rest.

Security enforcement and action authorization are different layers

It is tempting, and wrong, to describe this as “security vendors only do security.” Cisco AI Defense does real runtime enforcement, and enforcement that blocks is enforcement. The honest distinction is about what is being decided and what is left behind.

Security enforcement answers questions of the form: is this prompt malicious? is this MCP call risky? should this traffic be blocked? The output is a protective action plus telemetry.

Action authorization answers: is this specific action permitted, for this tenant, against this target, at this amount, under this policy version? The output is a verdict plus a durable artifact that can be re-checked by someone who was not there.

These compose well. A bank can want both: threat enforcement in the traffic path, and authorization plus evidence on the action path. We have written about the seam between them in AI governance vs. AI security. The mistake is assuming that because both can say “block,” they produce the same accountability.

Why cryptographic binding is the load-bearing part

An evidence record that says BLOCKED is an assertion. What makes it an argument is what the signature actually covers.

In EVE's hosted production, decision records are signed with ECDSA P-384 (SHA-384) on an AWS KMS-resident key — the private half never leaves the KMS boundary — and the production configuration refuses to fall back to symmetric HMAC. Production runs the v4 content-binding schema, which pulls the following into the signed payload:

That last group is the part people skip. Binding the policy version means the certificate does not merely claim a verdict; it commits to which rules were in force. Rewriting the policy afterward does not retroactively legitimize the decision, because the old policy identity is inside the old signature.

What “independently verifiable” has to mean

A production-signed EVE certificate can be checked with a standalone script, a published public key, and no network call to EVE — python verify_eve_decision.py record.json --pubkey eve-pubkey.pem. Altering any bound field produces a hash mismatch and the check fails. You can try this against a real signed record at the public verification portal, or read the mechanics in offline replay verification.

We have found no public Cisco material describing per-action cryptographic authorization certificates, policy-state binding, or vendor-independent offline verification for AI Defense. That is an absence of published evidence, not proof of absence — large platforms ship undocumented capability, and Cisco's audit and telemetry story is substantial. But a buyer who needs that property should require it in writing rather than infer it from the strength of the enforcement story.

The sovereign problem is not only about where enforcement runs

Sovereign and edge AI are usually framed as data-movement problems: keep inference local, keep data in-jurisdiction, reduce latency. Cisco's published architecture handles this well. In VPC and AI POD deployments, application, model, and agent data remain inside the customer environment, with only management-plane metadata sent to Cisco; the on-premises data plane maintains a bi-directional TLS gRPC stream to the AI Defense SaaS control plane, initiated only from the data plane.

That is genuine data sovereignty, and it is a sensible architecture. It is also worth naming precisely what it is: local enforcement with a centrally hosted management plane. The workload data stays put; the control relationship does not.

For most enterprises that trade-off is correct. For a subset — defense programs, certain public-sector deployments, institutions operating under jurisdictional isolation requirements — the harder question is what happens to evidence when the environment is disconnected, or when the vendor relationship ends. If a decision record is only interpretable inside a vendor console, the enforcement has been localized but the proof has not.

This is the requirement worth writing into procurement: not just “can the control run locally,” but can the evidence be verified by someone who has neither a connection to the vendor nor a reason to trust it.

Where EVE sits, stated at its actual maturity

EVE AI Core is built as an authorization and evidence layer rather than a threat-inspection layer. The intended chain is:

policy → deterministic authorization → policy-bound signed certificate → single-use execution authority → protected executor → side effect or prevention → offline verification

Because credibility is worth more than adjectives, here is where each link actually stands:

Two of those lines are less flattering than a marketing page would prefer. They are in here because a governance vendor that rounds “test-proven” up to “production” has disqualified itself from the argument it is trying to make.

Cisco and EVE are not the same product

Cisco brings things EVE does not: decades of threat intelligence, adaptive red-teaming against deployed models, SASE and network placement, and enterprise distribution measured in tens of thousands of accounts. If your problem is “an adversary is attacking our AI systems and we need coverage at the edge,” that is a strong answer and EVE is not a substitute for it.

EVE's layer is narrower and different: determining whether a consequential action was authorized under a named policy, preventing it deterministically when it was not, and leaving behind evidence that outlives the vendor relationship. Those layers can sit in the same architecture. Security infrastructure can determine that an interaction is dangerous. Authorization infrastructure determines whether the consequential action was permitted to happen — and produces independently verifiable evidence of that authority.

Questions worth putting in the evaluation

Whichever vendors are on your list, these separate placement from authority:

Ask them of us too. We have tried to answer them above at the maturity each one actually has, and the ones that are not production yet are labeled.

The next distinction

Cisco moving AI Defense onto sovereign and edge infrastructure is a real expansion, and it compresses the space where “we enforce at runtime” counts as a differentiator. That compression is healthy. It pushes the category toward the harder question.

As runtime enforcement becomes common, the remaining distinction is whether an enterprise can prove — not merely assert — that a consequential AI action was authorized under the policy it claims was governing at the time, and whether that proof holds up in the hands of someone with no reason to trust the vendor who produced it. Placement is close to solved. Verifiable authority is not.

See it decide, then verify it yourself

EVE CoreGuard evaluates a proposed AI action against your policy pack before it executes and returns ALLOWED, BLOCKED, or MODIFIED with a signed, policy-bound evidence record. Check a real production-signed certificate at the verification portal, read the architecture at EVE Proof, or book a governed pilot.

Frequently asked questions

Does Cisco AI Defense running at the edge remove the need for an authorization layer?

They answer different questions. Cisco AI Defense inspects and enforces security policy on prompts, responses, MCP interactions, and tool calls close to the workload. An authorization layer decides whether a specific consequential action was permitted under a named policy version, and emits signed evidence of that decision. A deployment can reasonably run both: threat enforcement in the traffic path, authorization and evidence on the action path.

Is Cisco AI Defense fully air-gapped?

Cisco's published architecture for VPC and AI POD deployments keeps application, model, and agent data inside the customer environment, with only management-plane metadata sent to Cisco. The on-premises data plane maintains a bi-directional gRPC stream to the AI Defense SaaS control plane, with the connection initiated only from the data plane. That is strong data sovereignty. Cisco's public material for AI Defense does not describe indefinite fully disconnected enforcement, so buyers who require it should ask for it explicitly.

What does it mean to bind a policy version into a decision certificate?

It means the signature covers not only the verdict but the identity of the policy that produced it — the policy version and charter hash — alongside digests of the exact request, the exact released response, and the per-rule results. Changing the policy after the fact, or altering any bound field, breaks the signature. Without that binding, an evidence record asserts a verdict but cannot prove which rules were in force when it was made.

Why does offline verification matter for sovereign and edge AI?

Because the auditor is often not in the same trust boundary as the enforcement point. If evidence can only be interpreted inside the vendor's console, you have localized enforcement without localizing proof. Verification that runs against a published public key, with no call back to the vendor, survives connectivity loss, contract termination, and vendor disputes.