Summary

  • Published on 5 September 2026, draft-das-eu-ai-act-execution-enforcement-00 is an active individual Internet-Draft by Sangam Das with an Informational target. It is not an IETF standard, Working Group document or regulatory endorsement.
  • The proposal holds a consequential operation as a non-effective Candidate Act, validates configured constraints, issues narrowly scoped act-bound authority and asks a Finality Sink to verify again immediately before the first protected external effect.
  • Its decisive limitation is topological. Section 35 says the property holds only for effects mediated by the protected boundary and shows a direct external API beside the sink as an unprotected route.
  • The linked v0.1.0 Python package demonstrates a single local effect-recording boundary. Both the draft and repository say it is a reference implementation, not a production security product or legal-compliance engine.
  • A credible deployment claim needs an effect-surface closure receipt: every selected consequence path, its boundary and route version, bypass-capable privileges, declared exceptions and negative tests proving invalid authority produces no effect.

The control is not the box

The draft arrives with a large title: Technical Enforcement of the EU AI Act and Global AI Laws Without Relying on Paper Policies. Its narrow engineering idea is easier to evaluate than that title. Computation and permission should be separated. An AI system may prepare a payment, message, file release, database mutation or actuator command, but the prepared operation remains a Candidate Act. A protected enforcement function checks whatever machine-readable conditions have already been selected. Successful validation creates authority for that exact act. At the last protected boundary, the Finality Sink verifies again before the effect is allowed.

That chain contains useful distinctions. Authentication of a workload is not permission for every act the workload can formulate. A previous policy check is not enough if the act, destination or policy epoch has changed. An audit record made after release is not prevention. A human approval for one recipient and amount should not be reusable for another. The sink procedure in revision 00 checks the Candidate Act digest, sink identity, expiry, policy epoch, revocation and consumption state, signature, non-bearer binding and required current state.

But a verifier can be impeccable and still be optional.

The security section shows an AI Agent branching in two directions: one branch reaches a direct external API, the other reaches the Finality Sink. The text then says the architecture does not establish finality protection for that API. The protected topology instead puts the relevant consequence behind the sink. This is not a footnote to the model. It is the boundary of the claim.

If a payment gateway is protected while a service account can call the settlement endpoint directly, only the gateway route is protected. If a publication service requires a valid act-bound permit while the agent can upload through a storage credential that the public site serves automatically, the publication consequence remains reachable. If a database proxy mediates one connection string while an administrator or fallback worker retains another, the proxy's denial cannot support a system-wide statement that the mutation was technically impossible.

None of those examples alleges that such a deployment exists. They show why the unit of assurance must be the effect surface, not the installed component.

“Selected” is a scope choice, not a loophole

Revision 00 does not demand that every token, tensor, database read or packet cross a Finality Sink. It says low-risk read-only operations may continue through existing paths and frames the target as a selected consequential transition. That is a sensible minimum-specification instinct. A system should not centralize every internal calculation merely to protect the moment at which money moves, a message leaves, a record commits or a machine actuates.

The economy of scope has a strict counterpart. Once an operator labels a consequence as protected, every route capable of producing that consequence must be inside the claim or named as an exclusion. “Selected transition” cannot mean “selected convenient endpoint.” The selection identifies the consequence; topology determines how many paths must be controlled to make that consequence non-effective without current authority.

The draft's own list makes the inventory problem visible. A Finality Sink might sit at an API gateway, tool server, database commit, message boundary, payment endpoint, operating-system interface, network egress, file-release interface, robotic controller, industrial control interface, publication service, cloud service or recipient-side service. In a real stack, more than one may matter. A message can leave through the normal broker and through an emergency transport. A file can be released by an application endpoint and by an object-store policy. A tool can be invoked through a router and through a vendor SDK.

Remote effects may become usable only at the recipient, beyond a local gateway's transaction.

This is also why atomicity cannot be inferred from a local check. The draft says a local implementation may combine verification, authority consumption and effect within one transaction. For remote effects, it points to destination-side sinks, idempotency keys, transactional outboxes, coordinated state machines and other mechanisms. It explicitly declines to claim that arbitrary Internet requests become atomic merely because they were validated locally.

The reference package proves a bounded case

The linked privacy-finality-reference release is useful because it runs. Version 0.1.0 constructs Candidate Acts, creates deterministic SHA-256 commitments, uses Ed25519 signatures and workload proof-of-possession, checks policy epochs and nonces, and records replay consumption and effect locally in SQLite. The demonstration uses a synthetic customer-support privacy scenario. A permitted request releases a minimum data set; an attempted purpose substitution is denied before the demo's effect record is written.

Its strongest sentence is not in the success output. The README says Non-Effective State is represented by the fact that the only effect-recording API is inside the Finality Sink. It then says bypass paths must be unavailable and that real network egress, database commits, payment submission, file exports, tool invocation or other consequence paths must be mediated equivalently.

That is honest running-code evidence for one local model. It is not proof about a production topology the code cannot see. The release is author-controlled, the repository describes itself as a reference implementation, and the draft lists what it does not provide: production HSM key management, production TEE attestation, distributed consensus, a complete PKI lifecycle, formal verification, high availability, side-channel protection, full remote atomicity or conformity assessment. Logical separation within one Python process also does not stop an unrestricted process administrator from reaching all state.

The correct conclusion is neither “paper policy solved” nor “the demo is worthless.” It is narrower. The package demonstrates that a check can be load-bearing when it is the only effect boundary in the model. A deployment must prove the equivalent premise for its own selected consequence.

Publish the closure receipt

An effect-surface closure receipt would turn that premise into an inspectable governance object. It should begin with the consequence, not the product: what exact external state becomes usable, and where does that first happen? The answer could be a settled payment instruction, a committed database row, a delivered tool command, a public object, an emitted network packet or an actuator state.

Next comes the path inventory. List every gateway, broker, connection, SDK, commit route, file interface, network egress, cloud control plane and recipient boundary that can produce the same consequence. For each path, record the Finality Sink or equivalent protected enforcement point, the route and service version, policy epoch, credential boundary and principal that can exercise it. Include fallback, break-glass, migration, batch and administrator paths. An unavailable path should be proved unavailable, not omitted because it is unofficial.

The receipt then needs negative evidence. Attempt the act with missing authority, an altered digest, the wrong sink binding, stale epoch, expired authority, revoked authority, replayed nonce and invalid workload proof. The expected result is not a warning or a log. It is no effect through that path. A test that stops at the local gateway is insufficient when the consequence becomes usable remotely; the observation point must reach the first usable external state.

Finally, publish the exceptions. Some read-only routes may properly sit outside the protected set. Some emergency mechanism may deliberately remain available under a different authority. The receipt should name those choices and narrow the claim accordingly. A path that has not been enumerated or tested receives the verdict unknown, not closed.

This receipt is my recommendation, not text from Sangam Das, the IETF or the European Union. It also does not prove that the supplied machine-readable constraint is lawful, complete or wise. The draft explicitly leaves legal classification, prohibited-practice decisions, risk-management adequacy, human-oversight sufficiency and conformity assessment to responsible authorities. The receipt proves only that a declared rule was technically unavoidable for a declared effect in a tested topology.

The proposal's legitimate standardisation surface

Revision 00 draws another necessary boundary. It says the legal meaning of AI laws is not an appropriate target for IETF protocol standardisation. The potentially interoperable surface is smaller: representations of Candidate Acts, canonicalisation, validation evidence, act-bound authorization, proof-of-possession, sink binding, freshness, revocation and error semantics.

Effect-surface evidence belongs beside that list, even if deployment-specific topology cannot be globally standardized. A protocol can define how a sink identifies itself and binds authority. A profile can state how an operator declares protected consequence classes and reports tests. No standards body can infer from the presence of one compliant sink that every alternate route has disappeared.

That restraint follows Heng Lu's running-code and minimum-specification discipline. Standardize the smallest common boundary that interoperability needs. Leave local architecture local. But do not let a component conformance result inflate into a system claim it cannot bear.

The news in this draft is therefore not only that an author proposes putting execution after governance validation. It is that the draft plainly admits the point at which the promise fails. A Finality Sink can reject every invalid act it sees. It cannot reject the act that never arrives.

Sources