How to Add Independent Compliance Attestation to Cisco AI Defense

1. What Cisco AI Defense Is

Cisco AI Defense is a runtime AI security platform. It operates at the network and application layer to protect AI workloads from adversarial inputs, unauthorized access, and policy violations. Its capabilities include:

• Guardrails: Input and output content filtering to enforce acceptable use policies on AI models.
• Prompt injection detection: Classification and blocking of adversarial prompt patterns before they reach the model.
• Content filtering: Output scanning to prevent generation of harmful, biased, or policy-violating content.
• Model access controls: Authentication and authorization for model endpoints, restricting which users, applications, and agents can invoke inference.

These are enforcement capabilities. They actively block threats and enforce organizational policy at runtime.

The attestation gap

AI Defense blocks threats but produces no independent, cryptographic proof that protections were active at the time of each inference. Its logs are internal to the Cisco platform. Auditors cannot independently verify that defenses were running without trusting Cisco's own telemetry. For regulatory frameworks that require independent evidence -- EU AI Act Article 9, NIST AI RMF Govern 1.7, CMMC AC-3 -- vendor self-reporting is insufficient. A separate, architecturally independent witness is required.

2. The Defense-in-Depth Gap

Security products enforce. Compliance requires proof of enforcement. These are structurally different functions, and conflating them creates a gap that auditors and regulators increasingly identify as a control deficiency.

Without independent attestation, an organization must rely on vendor self-reporting to demonstrate that its AI security controls were operational. This creates three problems:

• Single point of trust: If the security layer is compromised, its own logs are compromised with it. Evidence generated by the system under evaluation cannot independently prove the system was functioning.
• Audit independence: Regulatory bodies under the EU AI Act, NIST AI RMF, and CMMC require evidence from a system that is architecturally independent of the enforcement mechanism. A firewall's own logs do not prove the firewall was running -- an external witness does.
• Temporal coverage: Point-in-time security reports do not prove that controls were active during every inference. Continuous attestation requires per-event witnessing.

SWT3 closes this gap by witnessing the security layer from outside the security layer. It does not inspect, filter, or modify inference. It records what happened, whether it matched declared policy, and produces tamper-evident evidence that survives a compromise of the enforcement layer itself.

3. What SWT3 Witnesses

The following table maps Cisco AI Defense capabilities to SWT3 witness procedures. Each row describes what the enforcement layer does and what the witness layer records as independent evidence.

Each witness record is a SWT3 Witness Anchor -- a cryptographic fingerprint that is immutable, timestamped, and independently verifiable without access to the Cisco platform.

4. Procedure Detail

5. Quick Reference

Coverage key: Full = SWT3 directly witnesses the control and produces independent auditable evidence. Partial = SWT3 provides supporting attestation; the primary verification mechanism requires additional tooling or vendor cooperation.

6. Quick Start

The following examples demonstrate how to add SWT3 witnessing alongside Cisco AI Defense. The witness layer wraps the inference client. It does not replace or interfere with AI Defense's enforcement -- it records independent proof that the enforcement was active.

Python

pip install swt3-ai

from swt3_ai import SWT3Witness

witness = SWT3Witness(
    tenant_id="YOUR_TENANT",
    agent_id="cisco-ai-defense-proxy"
)

# AI Defense enforces guardrails at the network layer.
# SWT3 witnesses the guardrail state independently.

# Record that input guardrails were evaluated
witness.witness_guardrail(
    guardrail_name="cisco-prompt-injection-v2",
    threshold=0.85,
    evaluation_result="pass",
    model="gpt-4o"
)

# Record the access control decision
witness.witness_access(
    resource="model/gpt-4o",
    decision="permit",
    requester="app-service-account-12",
    method="oauth2-client-credentials"
)

# Flush anchors to the compliance ledger
witness.flush()

TypeScript

npm install @tenova/swt3-ai

import { SWT3Witness } from "@tenova/swt3-ai";

const witness = new SWT3Witness({
  tenantId: "YOUR_TENANT",
  agentId: "cisco-ai-defense-proxy",
});

// AI Defense enforces guardrails at the network layer.
// SWT3 witnesses the guardrail state independently.

// Record that input guardrails were evaluated
witness.witnessGuardrail({
  guardrailName: "cisco-prompt-injection-v2",
  threshold: 0.85,
  evaluationResult: "pass",
  model: "gpt-4o",
});

// Record the access control decision
witness.witnessAccess({
  resource: "model/gpt-4o",
  decision: "permit",
  requester: "app-service-account-12",
  method: "oauth2-client-credentials",
});

// Flush anchors to the compliance ledger
await witness.flush();

For connected mode (cloud ledger), set the SWT3_DSN environment variable and anchors will stream to the compliance ledger automatically. In local mode, anchors are stored locally and can be verified offline.

7. References

• SWT3 SDK Documentation -- Python and TypeScript API reference
• UCT Registry -- browse all compliance procedures
• Verify Anchor -- independent anchor verification
• Threat Model -- security architecture for the witness layer
• Integration Patterns -- common deployment architectures
• CI/CD Guide -- automated attestation in deployment pipelines