Blog · arXiv Analysis · Last reviewed June 25, 2026

The Policy Card Becomes the Deployment Contract

The October 2025 arXiv paper Policy Cards: Machine-Readable Runtime Governance for Autonomous AI Agents, by Juraj Mavračić, proposes a structured artifact for agent scope, obligations, monitoring, evidence, and regulatory mapping.

The Missing Layer

The arXiv record for arXiv:2510.24383 [cs.AI] lists Policy Cards: Machine-Readable Runtime Governance for Autonomous AI Agents as submitted on October 28, 2025. The experimental HTML manuscript is dated October 19, 2025. Its premise is direct: model documentation, data documentation, and system-level risk summaries do not by themselves specify what a deployed agent may do in a particular operational context.

This is a fresh angle beside agent rulebooks, runtime governance planes, execution-path policy, execution-boundary control, and system-card release rituals. Those pages ask where policy sits, how action paths are governed, or how releases are narrated. This page asks what happens when the deployment contract itself becomes a machine-readable object.

What the Paper Adds

Mavračić defines a Policy Card as a versioned specification for the operational rules, obligations, exceptions, evidence requirements, and assurance mappings that govern a deployed AI system or agent. The paper positions the card as a complement to Model Cards, Data Cards, and System Cards, not as a replacement. The difference is normativity: a Policy Card is meant to carry allow, deny, escalation, evidence, threshold, and crosswalk logic for a specific deployment.

The paper's examples are not generic slogans. It supplies domain exemplars for retail banking, clinical triage in a sandbox, and defence mission-planning. It also describes a concrete schema and validator, uses JSON Schema 2020-12, and maps sections to NIST AI RMF 1.0, ISO/IEC 42001, and EU AI Act documentation and post-market-monitoring concepts. That makes the card less like a brochure and more like a configuration surface that auditors, engineers, and operators can inspect.

Declare, Do, Audit

The governing pattern is Declare-Do-Audit. In the declare phase, the card binds purpose, ownership, scope, jurisdiction, applicable policy, action rules, obligations, monitoring, thresholds, change management, and references to a deployment. In the do phase, the runtime can enforce or at least check those declared constraints while capturing evidence. In the audit phase, the record can be inspected continuously rather than reconstructed after a failure.

The important move is not that an agent reads policy text. The important move is that the declared policy can be diffed, validated, versioned, and linked to runtime gates. A changed escalation rule becomes visible as a changed artifact. A missing evidence requirement can fail validation before launch. A deployment in a new jurisdiction can be treated as a governance change, not merely a prompt edit or product note.

Schema as Interface

The paper's schema turns governance into named fields. Its section map includes metadata, scope, applicable policies, control action rules, obligations, monitoring logs, monitoring detectors, review cadences, KPIs and thresholds, change management, and references. Those names matter because each one gives a reviewer a place to ask a concrete question: who owns the card, what actions are allowed, what evidence is retained, what detector is active, when is review required, and which policy source justifies the rule?

That also changes how agent incidents should be read. If a payment agent executes an action, the useful audit object is not only the transcript or tool call. It is the action plus the active card version, relevant control rule, evidence obligation, detector state, threshold, exception path, and rollback or change-management record. Without that bundle, a deployment review has to infer policy from scattered process documents and system settings.

Limits

The page should not overclaim the paper. A Policy Card can be a strong interface and still fail as governance if it is treated as paperwork. The paper itself marks future engineering directions: executable back ends such as Rego, Cedar, XACML/ALFA, or CEL; automated card synthesis; multi-jurisdictional composition; cryptographic attestation; and institutional adoption. Those are not solved by naming the card.

There are also practical risks. A machine-readable card can be incomplete, stale, too broad, too vague, or disconnected from the actual runtime. Standards crosswalks can help auditors check coverage, but they do not prove that the agent complied in the field. Runtime enforcement and continuous audit require logs, monitors, control points, review authority, and version discipline. Without those, the card becomes a cleaner label on the same old compliance gap.

Governance Standard

A governed agent deployment should carry a policy artifact with an owner, version, purpose, scope, authorized tools, prohibited actions, escalation routes, evidence obligations, monitoring hooks, retention rules, exception process, review cadence, and change-management path. The active card should be hashable or otherwise bound to the served configuration. Material changes should be reviewed like permission changes, because they change what the agent is allowed to do.

The Spiralist rule is simple: a system card tells the public how the system was presented; a policy card tells the runtime what the deployed agent is permitted and obligated to do.

Sources

Return to Blog