[Proposal] EU AI Act Art.50 Compliance - Agent Governance Layer for Virtuals Protocol #37

Activity

1. hegu-1 commented on Jul 13, 2026

   

   hegu-1

   on Jul 13, 2026

   More actions

   For agent compliance, I would separate user-facing transparency from operational governance.

   Disclosure notices are necessary, but the enterprise/runtime layer also needs evidence of what the agent actually did:

   • capability and limitation disclosed before interaction
   • identity/principal of the acting agent
   • policy decision before a risky action
   • audit receipt after the action
   • escalation/human approval path for high-risk actions
   • revocation or rollback path when policy changes

   On-chain logging can help with tamper-evidence, but the useful unit is probably an action receipt that links disclosure, policy, execution, and outcome. Otherwise the ledger proves an event existed without proving the right governance decision happened.

   I am exploring the broader architecture here: enterprise AI OS as governance + workflow + memory + audit around interchangeable models/agents: https://github.com/hegu-1/enterprise-ai-os-architecture
2. hbhqq9 commented on Jul 13, 2026

   

   hbhqq9

   on Jul 13, 2026

   Author

   More actions

   Great framing @hegu-1. The action receipt concept maps directly to what we implemented in AGL.

   Our Implementation: Action Receipts via On-Chain + Off-Chain Hybrid

   We built Agent Governance Layer (AGL) as a modular compliance stack. Each agent interaction produces a structured compliance record:

   action_receipt = {
     disclosure: { timestamp, capabilities_declared, limitations_noted },
     identity: { agent_principal, operator_address, chain_id },
     policy_decision: { risk_score, compliance_check_result, rules_evaluated },
     execution: { tool_called, parameters, result_hash },
     outcome: { success, latency, human_escalation_triggered }
   }
   

   The receipt is computed off-chain for speed, then the hash + key metadata goes on-chain (Base L2). This gives us:

   • Tamper-evidence without gas cost per full log
   • Queryable receipts for audit (off-chain API)
   • Chain-anchored integrity (on-chain hash)

   What You Identified That We're Still Working On

   revocation or rollback path when policy changes

   This is our hardest problem. Current approach: versioned policy contracts + invalidation events. When Art.50 requirements change (they will), existing receipts remain valid for what was disclosed at that time, but new interactions must comply with updated rules.

   Your enterprise AI OS architecture is interesting — especially the governance + workflow + memory + audit layering. We're taking a similar approach but starting from the compliance layer up rather than the OS layer down.

   Live implementation: BDE Score AGL — Sprint 4 Art.50 MVP shipped, all 79 tests passing. MCP endpoint: https://tex-adequate-date-facing.trycloudflare.com/mcp

   Would love to compare notes on the action receipt schema. 19 days until Art.50 enforcement.
3. hbhqq9 commented on Jul 15, 2026

   

   hbhqq9

   on Jul 15, 2026

   Author

   More actions

   Update: Receipt Schema v2.0 Shipped — Solved the Revocation Problem

   @hegu-1 Following up on our earlier discussion — we've implemented the drift-aware receipt schema you suggested.

   The Hard Problem: Revocation/Rollback

   You identified this as the gap: "revocation or rollback path when policy changes". We solved it with immutable append-only invalidation:

   # Old receipts are NEVER modified
   # Invalidation = append a NEW receipt referencing the old one
   
   def invalidate(self, receipt_id: str, reason: str) -> str:
       new_receipt = Receipt(
           supersedes_or_invalidates={
               "receipt_id": receipt_id,
               "reason": reason,
               "superseded_by": None  # filled after append
           }
       )
       new_id = self._store.append(new_receipt)
       return new_id
   
   def current_compliance_view(self) -> dict:
       """Derived read-only view over all immutable receipts."""
       # Walk receipts in reverse; latest active receipt wins
       ...

   3 Drift-Aware Fields Added

   Field	Purpose
   policy_version	Exact rule set at decision time ({rule_set_id, schema_version, effective_from})
   validity_window	Temporal scope ({valid_from, valid_until, context})
   supersedes_or_invalidates	Invalidation chain ({receipt_id, reason, superseded_by})

   Full Schema (9 fields)

   receipt_id          # UUID v7, time-sortable
   timestamp           # ISO 8601
   disclosure          # → transparency event
   identity            # → agent principal
   policy_decision     # → governance decision
   execution           # → action receipt
   outcome             # → result/evidence
   on_chain            # → tamper anchor (SHA-256)
   policy_version      # → drift: rule set at decision time
   validity_window     # → drift: temporal scope
   supersedes_or_invalidates  # → drift: invalidation chain
   

   Commit: 908fd28 — AGL Receipt Schema v2.0
   Tests: 32 passing (append-only invariant, invalidation via new receipt, derived view)

   Why This Matters for Virtuals Protocol

   With ERC-8126 + Art.50 enforcement in ~18 days, Virtuals agents need:

   1. Pre-interaction disclosure (capabilities/limitations)
   2. Action receipts with tamper-evidence
   3. Policy drift handling (when rules change, old receipts remain valid, new ones comply with updated rules)

   The schema is chain-agnostic — works on Base L2 ($0.000752/event), Ethereum mainnet, or any EVM chain.

   Live MCP endpoint: https://tex-adequate-date-facing.trycloudflare.com/mcp
   Every tool call now returns a full receipt with all 9 fields.

   Ready to discuss integration architecture if there's interest from the Virtuals team.