Compliance Frameworks

ShieldAgent maps to the three major AI governance frameworks: EU AI Act, ISO 42001, and NIST AI RMF. Evidence is collected automatically from the runtime audit trail.

EU AI Act

Annex III deadline: 2 Dec 2027

The EU AI Act imposes documentation, risk management, and human oversight requirements on high-risk AI systems. ShieldAgent generates Annex IV technical documentation from your live proxy data, covering, in part, 5 of Annex IV's 9 points (1, 2, 3, 4 and 6) — points 5, 7, 8 and 9 are not covered. For Verdict API (Positions 2 & 3) deployments, Annex IV documentation includes the customer's enforcement mechanism and the REST verdict-confirmation enrollment rate — client-reported telemetry, not independent proof that your application code applied the verdict.

Coverage

✓S1General system description (Annex IV, point 1)

✓S2Design & development process (Annex IV, point 2)

✓S3Monitoring & human oversight (Annex IV, point 3)

✓S4Appropriateness of performance metrics (Annex IV, point 4)

✓S5Changes through the AI system lifecycle (Annex IV, point 6)

✓S6Assessment of human oversight measures (sub-item of Annex IV points 2 and 3)

✓S7Accuracy, robustness & cybersecurity (sub-item of Annex IV points 2 and 3)

✓S8Data governance & data management (sub-item of Annex IV point 2)

EU AI Act example →

ISO 42001

International Standard

ISO/IEC 42001:2023 is an AI management system standard. ShieldAgent maps audit evidence to clauses 4–10, but none is automatically satisfied by runtime events. Each clause requires your own documentation and attestation before it can be marked covered.

Coverage

○Clause 4Context of the organization

○Clause 5Leadership & AI policy

○Clause 6Planning & risk assessment

○Clause 7Support & competence

○Clause 8Operations & AI system controls

○Clause 9Performance evaluation & audit

○Clause 10Improvement & incident management

Risk scoring example →

NIST AI RMF

US voluntary framework

The NIST AI Risk Management Framework provides a voluntary structure for managing AI-related risks. It organizes controls across four core functions: Govern, Map, Measure, Manage.

Coverage

✓GOVERNPolicies, accountability, culture

✓MAPContext & risk identification

✓MEASUREMetrics, testing, monitoring

✓MANAGEPrioritize, respond, recover

Compliance example →

Compliance by Deployment Position

Compliance evidence strength depends on where ShieldAgent sits in your architecture. Infrastructure-enforced positions provide automatic, tamper-evident enforcement records. The Verdict API (Positions 2 & 3) places enforcement responsibility with the customer.

Verdict API (Positions 2 & 3) — EU AI Act Art. 26 requirement

EU AI Act Article 9's risk management system is a provider obligation, not a deployer one. As a deployer, Article 26 instead requires you to monitor the system's operation per the provider's instructions, assign competent human oversight, and — to the extent you control them — keep the high-risk system's automatically-generated logs for at least six months, unless other applicable law requires a different period. When using the Verdict API (Positions 2 & 3), enforcement is performed by the customer's own code — not by ShieldAgent infrastructure. To support those Article 26 obligations, organizations should:

Document how the enforcement mechanism fits into their own operational monitoring of the system.
Call POST /tenants/:tenantId/verdict-confirmations with JSON {"auditEventId":"evt-uuid","executed":true} after each verdict with the scan response auditEventId and the boolean executed value reflecting your code’s action. The audit trail records a client-reported callback, not independent proof of enforcement. REST authentication.
Track the aggregate REST verdict-confirmation enrollment rate across Verdict API verdict-scanned traffic. ShieldAgent's own S3.5 Annex IV gap-analysis control requires at least 80% for these deployments; this is not an EU AI Act threshold. The control is vacuously met before any verdict scans occur, and a single missed request does not fail it on its own. Once the aggregate rate for requests to POST /tenants/:tenantId/verdict-confirmations drops below that threshold, the control is marked not met in Annex IV reports.

Using the Verdict API without enforcing verdicts may compromise your compliance posture for high-risk AI systems. For proxy blocking of routed calls in enforce mode, consider Position 1 (inline proxy); shadow mode does not block.

Position 1 — Infrastructure-enforced (Inline Proxy)

Inline proxy between agent and MCP server

For calls routed through the inline proxy in enforce mode, ShieldAgent applies allow/deny decisions and logs policy decisions as tamper-evident infrastructure evidence. In shadow mode it records would-be denials and forwards the calls without blocking. Direct connections that bypass the proxy are outside this enforcement path.

Positions 2 & 3 — Verdict API (REST)

Customer-side enforcement via REST API

ShieldAgent issues a security verdict; the customer's code decides whether to execute or reject the request. A POST to /tenants/:tenantId/verdict-confirmations records a client-reported callback for that verdict — it is not independent proof the verdict was applied. Compliance requires the customer's own enforcement controls. Annex IV documentation includes the customer's enforcement mechanism and the aggregate REST verdict-confirmation enrollment rate as product telemetry.

Automatic Evidence Collection

ShieldAgent collects compliance evidence continuously as your agents operate. The audit trail is immutable and Merkle-verified — every record is tamper-evident.

Risk scoring Per-agent risk scores recalculated on a fixed interval (5 minutes by default) — maps to S4 performance metrics and NIST MAP

Policy decisions Every allow/deny/shadow decision logged with timestamps — maps to S3 oversight and NIST MANAGE

Audit trail Immutable event log with Merkle integrity proofs — maps to S8 data governance and ISO 42001 Clause 9

Anomaly detection Statistical behavioral analysis — maps to S7 robustness and NIST MEASURE

Human review queue Tool calls flagged for human approval — maps to S6 human oversight mandate

Incident log Security events and resolution timeline — maps to ISO 42001 Clause 10 and NIST MANAGE

Audit Retention

Framework	Requirement / note	Config
EU AI Act — audit logs (Art. 26(6))	Statutory minimum for the high-risk system's own automatically-generated logs under the deployer's control: 6 months, unless other applicable law requires a different period. SHIELDAGENT_AUDIT_RETENTION_DAYS=365 is a parsed value for the self-hosted proxy's own ephemeral debug log — it configures no delete or prune path. ShieldAgent SaaS plans resolve retention per billing tier, from 182 days (Solo/Team) up to 1,825 days / 5 years (Enterprise Cloud); the self-hosted Enterprise On-Prem deployment sets its own window separately, up to 3,650 days / 10 years.	SHIELDAGENT_AUDIT_RETENTION_DAYS=365 (parsed, not enforced)
ISO 42001	Does not mandate a specific retention window; align to your own documented policy.	SHIELDAGENT_AUDIT_RETENTION_DAYS=<your value> (parsed, not enforced)
NIST AI RMF	Organization-defined	SHIELDAGENT_AUDIT_RETENTION_DAYS=<your value> (parsed, not enforced)
SOC 2	Does not mandate a specific retention window; align to your auditor-agreed scope.	SHIELDAGENT_AUDIT_RETENTION_DAYS=<your value> (parsed, not enforced)

SOC 2 & Verdict API: Verdict API (Positions 2 & 3) deployments generate continuous control-monitoring signals mapped to a subset of SOC 2 CC6/CC7 technical controls, when combined with the customer's own enforcement controls. This is not a SOC 2 attestation — attestation is issued only by a licensed CPA firm after its own evaluation. The audit trail records every verdict issued and every REST verdict-confirmation request as supporting evidence for that evaluation.

Config column: SHIELDAGENT_AUDIT_RETENTION_DAYS is parsed and passed to the self-hosted proxy's own ephemeral per-pod debug logger, but is not used there to retain or purge anything. ShieldAgent's durable, per-tenant audit retention instead runs as a separate background job gated behind RETENTION_PRUNE_ENABLED, which is off by default. None of the figures in this table describe a retention window that is purged by default.