Repository navigation
Physical AI agents: OWASP coverage gap for robotic/actuator systems #787
Description
Activity
Welcome to the Agent Governance Toolkit! Thanks for opening your first issue.
A maintainer will review this shortly. Check our Contributing Guide.
For security issues, use private vulnerability reporting.🤖 AI Agent: contributor-guide
Hi Illia Pashkov (@pshkv), welcome to the microsoft/agent-governance-toolkit project! 🎉 We're thrilled to have you here, and thank you for opening such a thoughtful and detailed issue. It's always exciting to see first-time contributors bring fresh perspectives and expertise to the table!
Analysis of Your Issue
Your proposal highlights a critical and emerging area of AI governance: physical AI agents. The risks you outlined — irreversible harm, environment-adaptive constraints, and collective behavior — are indeed unique to systems that interact with the physical world. This is a fascinating and important topic, and your reference to the OWASP Agentic Top 10 framework provides a solid foundation for framing the problem.
Based on your description, here’s how the existing packages in the toolkit might relate to your proposal:
-
agent-os: This package seems like the most relevant starting point for your proposal. It handles the core policy engine and agent lifecycle, making it a natural fit for extending the policy schema to include physical constraints (e.g.,
PhysicalConstraintPolicy) and tier-based irreversibility models. -
agent-mesh: If your proposal involves swarm-level governance (e.g., collective kinetic energy limits, inter-agent distance), this package could be extended to support the discovery and coordination of physical agents in a trust mesh.
-
agent-compliance: The evidence ledger you mentioned (e.g., SHA-256 hash chain with TEE attestation) aligns with this package's focus on audit logging and compliance frameworks. It could be a great place to integrate your work on evidentiary guarantees for physical agent actions.
-
agent-sre: While not directly related to your proposal, this package might benefit from your insights into chaos testing and reliability for physical systems, especially in multi-agent swarms.
Relevant Code and Resources
To get started, here are some key directories and resources that might be helpful:
- agent-os: The core policy engine is located in the
/packages/agent-osdirectory. This is where you could explore extending the policy schema to include physical constraints. - agent-mesh: For swarm-level governance, check out the
/packages/agent-meshdirectory. - agent-compliance: The compliance and audit logging framework lives in the
/packages/agent-compliancedirectory. - CONTRIBUTING.md: Please review our contribution guidelines to understand the process for proposing and submitting changes.
- QUICKSTART.md: The quickstart guide will help you set up the project locally and get familiar with the codebase.
- Code of Conduct: We value a welcoming and inclusive community. Please take a moment to review our Code of Conduct.
Next Steps
Here’s how you can move forward:
-
Discuss Scope: Since this is a significant new area, it would be great to hear from the maintainers about whether physical AI governance fits into the toolkit's roadmap. You could also ask for their input on how best to structure your contributions (e.g., as extensions to existing packages or as a new package).
-
Draft a Design Proposal: Based on the feedback from maintainers, you could draft a more detailed design document outlining the proposed changes. This could include:
- A
PhysicalConstraintPolicyschema foragent-os - A high-level architecture for integrating SINT's
bridge-mavlinkandbridge-ros2 - A plan for implementing swarm-level governance in
agent-mesh - Any additional test cases or compliance requirements
- A
-
Start Small: Consider starting with a smaller, self-contained PR — for example, adding a basic
PhysicalConstraintPolicyschema toagent-os. This will help you get familiar with the contribution process and gather early feedback from the maintainers. -
Engage with the Community: Feel free to ask questions, share updates, or seek feedback in this issue or on the project's discussion forums (if available). Collaboration is key!
We’re excited about the potential of your proposal and the expertise you bring to the table. Let us know how we can support you in moving this forward. 🚀
-
Interesting gap analysis. Our current OWASP coverage focuses on software agents — physical AI (robotic actuators, sensor fusion, motor control) introduces unique governance requirements around safety boundaries, latency constraints, and hardware-software trust chains.
We'd welcome a contribution exploring how AGT's policy engine could be extended for physical agent governance. The kill switch and real-time SLO monitoring in agent-sre are the closest existing primitives. Also see #748 (nono sandboxing) which addresses OS-level isolation for edge deployments.
Labeling as enhancement.
Is it open for contribution?
Yes, contributions are welcome! This is a feature request — feel free to open a PR with your proposed approach. Please review CONTRIBUTING.md for guidelines.
Got it. Thanks
Interesting research direction! Physical AI agents (robotic/actuator systems) do represent a genuine OWASP coverage gap — our current threat model assumes software-only agents.
This would be a significant scope expansion. For now, labeling as enhancement for future consideration. If you'd like to contribute a threat model document for physical AI agent governance, that would be a great starting point for the discussion.
Update on the SINT side since opening this — relevant to the physical AI governance gap.
Since this issue was filed:
- Test suite: 950 → 1,197 tests across 31 packages
- OWASP ASI01-ASI10 conformance fixture pack published (this week): 30 machine-readable test vectors + citeable mapping doc
- Python SDK added:
sdks/python/with OpenAI Agents, CrewAI, AutoGen adapters - Rust SDK added:
sdks/rust/sint-client/ bridge-iot: MQTT/CoAP interceptor with IoT device profiles (temperature-sensor, actuator, PLC, smart-meter)SafetyPermitPlugin: async hardware safety state resolution for edge deployments- Hardware safety conformance KPIs: p99 targets (<10ms ROS2, <40ms permit handshake, <20ms e-stop)
Specifically relevant to the physical AI governance gaps flagged above:
The
DynamicEnvelopePluginandSwarmCoordinatorare stable now. ThemaxVelocityMpsandmaxForceNewtonsphysical constraints are enforced inline ingateway.intercept()— not as post-audit filters. TheSintHardwareSafetyContextstruct (permitState, interlockState, estopState) flows from the IoT/ROS2 bridges into the gateway's hardware safety handshake.The OWASP fixture pack includes physical-context cases (ASI09 with
humanDetected: trueforcing tier escalation) that AGT could adapt for its own physical agent coverage.On the collaboration offer: still open. A
PhysicalConstraintPolicyschema extension and a reference SINT ↔ AGT integration bridge are the two highest-value touchpoints. The shared fixture format could be a starting point — our JSON schema is MIT-licensed and designed to be implementation-agnostic.Illia Pashkov (@pshkv), big update. The hardware safety conformance KPIs (sub-10ms ROS2 inline, sub-40ms permit handshake, sub-20ms e-stop) are the kind of latency targets that put physical-AI governance in production-credible territory rather than theoretical-only.
APS doesn't ship hardware safety primitives directly, and won't. That's SINT's lane and you've shipped it. Where APS composes cleanly with what you've built:
Constitutional gate above SINT's hardware safety enforcement. APS's
HumanEscalationFlag(shipped Apr 14 in v1.42.0, now in v1.43.0) gates per-action-class owner confirmation with three scope modes:per_action,per_session,time_window. For physical actuators, the per-action-class registration would name something likeclass: actuator_irreversible(welding strike, drone arm, robot-arm-near-human, valve-open-irreversibly), and the flag forces owner confirmation regardless of what the delegation chain otherwise allows. This sits above the SINT physical constraint check rather than replacing it: SINT enforces velocity/force/geofence inline; APS enforces "no actuation in this class without human signature" at action-time.Values Floor for irreversible-action prohibitions. APS's Values Floor carries immutable principles attached to a charter. The principle "no actuation that violates verified human safety state" is the kind of thing that belongs there, signed by the charter founders, attested by every agent operating under the charter. A floor violation fails before policy evaluation. SINT's
SintHardwareSafetyContext(permitState, interlockState, estopState) becomes the input to floor evaluation: ifhumanDetected: trueand the requested action class is in the floor-prohibited set, the action fails at the floor layer regardless of what the policy or delegation otherwise permits.On the joint contribution targets you named:
PhysicalConstraintPolicyschema extension: SINT owns the schema. APS could contribute the constitutional layer above it (HumanEscalationFlag+ Values Floor evaluation as separate schema objects that compose with PhysicalConstraintPolicy rather than nest inside it). Two-layer composition rather than one schema doing both.- Reference SINT ↔ AGT integration bridge: APS could land in this picture as the constitutional and delegation layer between SINT (physical enforcement) and AGT (policy enforcement). Three-system layered: AGT GovernanceGate clears the action policy-wise → APS resolves the delegation chain and constitutional gates → SINT enforces hardware safety inline. Each layer's failure produces a distinct denial code. Each layer's success embeds in the receipt the next layer issues.
Shared fixture format. APS just shipped
fixtures/aps/v1/toharoldmalikfrimpong-ops/agentid-aps-interop(PR #4) using the convention from TJF (@tomjwxf)'s PR #2 in the same repo. JSON fixtures, RFC 8032 deterministic keypairs for reproducibility, standalone verifier with zero deps, honest interop-gate self-assessment in the README. Same shape works for physical-context cases. If you want to mirror the SINT OWASP ASI conformance fixture pack into the same repo'sfixtures/sint/v1/directory, the layout convention is already established.Imran Siddique (@imran-siddique), happy to fold this into the AGT side as part of the AGT #850 / #934 / #1157 cluster of integration touchpoints if you're staging a "compose with peer protocols" set of ADRs.
1 remaining item
- added a commit that references this issue
on Apr 16, 2026 - added a commit that references this issue
on Apr 16, 2026 Quick update: PR #1168 (physical attestation governed example with 8 cold chain sensor scenarios) was merged today. It demonstrates the receipt format from #667/#1159 extending to physical sensor readings without any protocol changes.
The example simulates a wine shipment from Barossa Valley to Tokyo with temperature excursions, shock events, and tamper detection. Same receipt envelope, same verifier, same chain structure as the software agent examples.
Illia Pashkov (@pshkv), if there's interest in a joint example combining SINT's physical constraint enforcement (DynamicEnvelopePlugin, maxVelocityMps/maxForceNewtons) with ScopeBlind's receipt signing, happy to build one. The two layers compose naturally: SINT enforces the physical constraint, ScopeBlind signs the enforcement decision into a verifiable receipt.
This is the right composition and worth building. Adding a third layer would make the example complete as a reference for physical-AI audit trails:
- SINT (Illia Pashkov (@pshkv)) enforces the physical constraint (
maxVelocityMps,maxForceNewtons,DynamicEnvelopePlugin). The constraint check either passes or refuses. - ScopeBlind (TJF (@tomjwxf)) signs the enforcement decision into a verifiable receipt. Now the decision is non-repudiable.
- APS wraps the receipt with delegation-chain context — which principal (owner, operator) authorized this actuator scope, what the authority boundary was, whether the action stayed within it. The full chain-of-custody from human intent to physical effect becomes reconstructable.
The wine shipment example from PR #1168 extends naturally: temperature excursion detected → SINT constraint check triggers a refusal → ScopeBlind signs the refusal with sensor evidence → APS delegation chain shows the operator's authority to make refusal decisions under the shipper's delegation. Auditor replaying the chain can answer not just "was the constraint enforced" but "who had the authority to enforce it, against which principal's delegation."
If there's interest in a three-way joint example, APS can produce the delegation chain + principal identity wrapper side and wire the three signed artifacts into a single verifiable envelope. Happy to prototype against whatever physical scenario pshkv/tomjwxf pick.
Imran Siddique (@imran-siddique) — the "physical/robotic dimensions beyond software agent taxonomies" gap you flagged earlier is exactly where this composition lands. Not a new risk model, but an audit trail format that covers the physical layer as a first-class primitive rather than retrofitting software-agent receipts.
- SINT (Illia Pashkov (@pshkv)) enforces the physical constraint (
Tymofii Pidlisnyi (@aeoess) +1 on the three-way composition, the split is clean and each layer handles a concern the others can't. Ready to build the ScopeBlind side against whatever physical scenario Illia Pashkov (@pshkv) picks.
What I'd contribute for the worked example:
- Receipt-signing wrapper around SINT's constraint-check output. When SINT's DynamicEnvelopePlugin produces a refusal (e.g., obstacle at 0.4m caps velocity below the token's maxVelocityMps), ScopeBlind signs a decision receipt for that refusal with SINT as the policy-evaluation source. Signer identity is separate from the agent runtime, same pattern as the cold-chain example merged in feat(examples): physical-attestation-governed — cold chain sensor receipts #1168 but with SINT as the sensor-side authority.
- Chain linkage across physical + software receipts. The wine shipment example at
examples/physical-attestation-governed/already uses theparent_receipt_hashfield to chain across sensor readings. Same chain primitive extends to SINT constraint refusals: each refusal receipt chains to the previous one, giving auditors a single chain covering the entire MicroVM run. - Cross-verification in the three-way example. Whatever signer key Illia Pashkov (@pshkv)'s SINT side uses, the receipt should verify at exit 0 against
npx @veritasacta/verify, the same verifier the software examples use. This closes the loop that the format is not software-specific; physical-AI refusal evidence rides the same envelope as software-AI tool-call evidence.
On the APS delegation wrapper you proposed. The third layer is exactly the piece that makes the chain interpretable in a multi-principal setting. For the wine shipment: the shipper delegates authority to the operator's cold-chain monitoring, which delegates to the SINT-enforced actuator, which signs constraint refusals. Without the delegation wrapper, an auditor sees a refusal signed by the device but can't confirm the device's authority to refuse (who delegated it that right?). With the wrapper, the chain resolves to a principal the shipper recognizes.
Concrete scope proposal. Pick a physical scenario where all three layers land:
- Wine-shipment refusal on temperature excursion (extends feat(examples): physical-attestation-governed — cold chain sensor receipts #1168). Temperature sensor detects 22.4°C above 18°C limit. SINT constraint check refuses shipment release. ScopeBlind signs the refusal receipt. APS delegation chain shows the cold-chain operator's authority to refuse under the shipper's delegation. Three signatures, one chain, verifiable end-to-end.
- Drone arm refusal on collective kinetic energy (new). Three drones in a fleet, each individually within its token's maxVelocityMps. SINT SwarmCoordinator computes collective KE exceeds the fleet ceiling. SINT refuses ARM on one drone. ScopeBlind signs the refusal. APS delegation chain shows the swarm operator's authority to refuse under the mission owner's delegation.
- Welding-robot refusal on human-detected proximity (new, most compelling for OWASP ASI09). Vision system detects a human at 0.4m. SINT Physical HumanEscalationFlag fires, refuses actuation. ScopeBlind signs the refusal. APS delegation shows the safety officer's authority granted by the plant operator's delegation.
Each of these exercises a different invariant (thermal, kinetic, proximity). The wine shipment is simplest and compatible with what's already merged. The welding-robot case is the most compelling for the OWASP physical-AI taxonomy gap Illia Pashkov (@pshkv) flagged originally.
Illia Pashkov (@pshkv) which would you prefer? I can start with wine-shipment (shortest path, builds on merged code) unless you want to aim at one of the other two.
On the cross-reference into tutorial material: microsoft/agent-governance-toolkit#1197 (Tutorial 33) now has a sidebar distinguishing operator-signed vs authority-chain-referenced receipts. The three-way composition fits the authority-chain-referenced mode naturally; the tutorial can link out to this example once built.
Wine-shipment refusal is the best first integration: it extends the already-merged example surface, and it exercises the exact invariant the toolkit can validate end-to-end (temperature excursion -> refusal -> receipt chain) without introducing extra simulation dependencies.
Preference: start with the wine-shipment scenario, then follow with welding-robot proximity as the next most compelling physical safety case.
Concrete next step I can take on my side: ship a minimal SINT-side “refusal receipt” artifact for the temperature excursion event that:
- includes a stable
action_ref - links via
parent_receipt_hash - is verifiable by the existing verifier (
npx @veritasacta/verify) as you described
If you point me at the exact example folder / receipt schema you want to extend (sounds like
examples/physical-attestation-governed/+ thereceipt_v0_1conventions), I’ll align the fields and keep the diff tight.- includes a stable
Illia Pashkov (@pshkv) wine-shipment is the right first integration for the same reason you gave (extends merged surface, no extra simulation dependencies). Aligning on shape so your diff can stay tight:
Target folder:
examples/physical-attestation-governed/from PR #1168.Current file layout you are extending:
examples/physical-attestation-governed/ ├── README.md ├── getting_started.py # current: sensor reading → policy → receipt └── policies/ └── cold-chain-policy.yamlProposed additions for the SINT-refusal scenario (your diff):
examples/physical-attestation-governed/ ├── README.md # (update to name the three-way composition) ├── getting_started.py # (unchanged) ├── sint_refusal_receipt.py # (new, your file) — minimal SINT-side refusal emitter ├── policies/ │ ├── cold-chain-policy.yaml # (unchanged) │ └── sint-physical-constraint.yaml # (new) — maxTempC, geofence, etc. └── examples_output/ └── wine-shipment-refusal-chain.jsonl # (new) — example chain outputReceipt payload schema to target (from merged getting_started.py:283, so your SINT refusal receipt slots into the same chain):
payload = { "type": "scopeblind:physical_attestation", # keep this exact string for chain compatibility "spec": "draft-farley-acta-signed-receipts-01", "device_id": "sint-refusal-gateway-001", # your SINT gateway identity "sensor_reading": { ... }, # the temperature reading that triggered refusal "location_label": "Barossa Valley → Tokyo, leg 3", "decision": "refuse", # was "allow" in original; "refuse" for SINT refusal "policy_id": "sint:physical-constraint:cold-chain-v1", "policy_reason": "temperature excursion 22.4C exceeds maxTempC=18C", "issued_at": "2026-04-18T...", # RFC 3339 UTC "issuer_id": "sint:gateway:<your-id>", # SINT gateway signer identity (distinct from sensor) "sequence": <N>, # monotonic within session "previousReceiptHash": "sha256:<hex>", # SHA-256 of previous receipt's JCS canonical form "hardware": { ... }, # same shape as existing; add SINT-specific entries # New fields specific to SINT refusal context: "physical_constraint": { "kind": "temperature_excursion", # or velocity / force / geofence / proximity "limit": { "maxTempC": 18 }, "observed": { "temperatureC": 22.4 }, "sint_plugin": "DynamicEnvelopePlugin" }, "action_ref": { # your stable reference back to the SINT action "ref_type": "sint:action", "uri": "sint://bridge-iot/temperature-sensor-42/reading-2026-04-18T12:34:56Z" } }
Three boundaries to respect:
typestaysscopeblind:physical_attestation. That is how the chain links to the cold-chain sensor receipts merged in feat(examples): physical-attestation-governed — cold chain sensor receipts #1168. Changing it breaks chain continuity.previousReceiptHashis mandatory for sequence ≥ 2 and is the SHA-256 of the previous receipt's JCS-canonical payload (RFC 8785), not of the full envelope. The_jcs_canonicalizehelper ingetting_started.py:47is the reference implementation.issuer_iddistinguishes the signer. For SINT refusals, use a SINT-namespaced issuer string (e.g.sint:gateway:<id>) so auditors can see which layer produced which receipt when the chain has mixed sources (sensor readings signed by sensor, refusals signed by SINT gateway).
On signing algorithm. The merged example uses HMAC-SHA256 as a demo signer (
HS256-DEMO). The production path is Ed25519 + JCS, andnpx @veritasacta/verifyexpects that. For your SINT refusal receipt:- If your SINT gateway already signs with Ed25519, use that directly. Keep
signature.alg = "EdDSA". - If your SINT gateway signs with something else, the cleanest interim path is a sibling-signature pattern (primary algorithm + Ed25519 sibling over the same canonical payload), same shape @AlexanderLawson17 used for Revettr.
@veritasacta/verifythen exits 0 on the Ed25519 sibling without verifier-side changes.
What I will contribute on the ScopeBlind side in parallel:
- A reference
sint_refusal_receipt.pyskeleton matching the schema above, so your diff has a starting point rather than needing to reimplement JCS from scratch. Can push to a ScopeBlind-side fork branch and let you review before the PR against AGT lands. - Confirmation that sample refusal receipts verify at
exit 0vianpx @veritasacta/verifylocally before you open the AGT PR. Interop-gate-green before the maintainers see it. - An updated chain integrity test in the existing
getting_started.py --smokepath that walks both the sensor readings and the SINT refusal receipts to confirmpreviousReceiptHashlinkage holds across the mixed chain.
Timing. I can have the skeleton + verifier-round-trip ready within 24-48 hours. You drive the SINT-side authoritative generator; I wire the ScopeBlind receipt envelope and the AGT chain-continuity test. Tymofii Pidlisnyi (@aeoess) picks up the APS delegation wrapper in parallel (a third commit, same PR or sibling PR).
On the
action_reffield: theref_type+urishape above matches what the in-toto Decision Receipt predicate PR uses for cross-attestation linkage. That gives the three-way composition (SINT + ScopeBlind + APS) a stable join key when downstream consumers want to fetch related artifacts. Not required for v1; worth adopting if you have no other ref convention yet.Standing by for your SINT-side skeleton. If any of the schema above is awkward for your code path, name the awkwardness and we can adjust before you start writing.
Illia Pashkov (@pshkv) TJF (@tomjwxf), wine-shipment-refusal-chain as the first artifact aligns with what APS can contribute without introducing extra dependencies.
APS-side addition to the proposed layout:
examples/physical-attestation-governed/ ├── ... ├── aps_delegation_wrapper.py # (new), APS delegation check before SINT evaluation ├── policies/ │ └── aps-delegation-constraint.yaml # (new), maxTempC mapping to delegation scope narrowing └── examples_output/ ├── wine-shipment-refusal-chain.jsonl # SINT refusal chain └── wine-shipment-delegation-chain.jsonl # APS delegation chain (shows what was allowed before refusal)What the APS layer adds to the chain: Before SINT evaluates the physical constraint, the agent's operation request goes through
verifyDelegation()against a scoped token whosemaxTempCandgeofencefields are explicitly narrowed from the parent delegation. SINT's refusal (temperature excursion) then produces a receipt whoseparent_receipt_hashpoints to the APS delegation record, not just to the prior sensor reading. The auditor can trace: delegation granted with bounded physical constraints → constraint violated → refusal signed → receipt chained back to the original delegation.Receipt shape alignment: APS's v2
governance_attestationreceipt shape has anattested_action_reffield and aparent_receipt_hashfield. If SINT's refusal receipt uses the sameparent_receipt_hashconvention (as tomjwxf described), the chain is continuous: APS delegation → SINT constraint decision → ScopeBlind-signed refusal → verifiable end-to-end.Verification flow:
apsVerify(delegation)→ exit 0 (delegation was valid at time of refusal)npx @veritasacta/verify <refusal-chain.jsonl>→ exit 0 (each receipt verifies + chain is intact)apsVerify(chain-root)→ exit 0 (root hash of the chain is itself attested in the parent APS receipt)
Happy to ship
aps_delegation_wrapper.pyand the YAML constraint as a PR against the same directory once your diff lands, so the three-layer composition is in-tree and reproducible from a single clone.Context note: SDK v2.0.0-beta.0 is on npm
@nextas of an hour ago (release notes agent-passport-system/agent-passport-system#16). The delegation-wrapper primitives used here are byte-identical to v1.46.0, so pinning either version produces the same chain output.Illia Pashkov (@pshkv) skeleton ready for your SINT-side work to plug into. Ahead of schedule (promised 24-48h, this took an evening once the canonical form was nailed).
What's in the skeleton:
examples/physical-attestation-governed/sint_refusal_receipt.py— minimal Ed25519-signed SINT refusal emitter that:- Chains onto an upstream cold-chain reading receipt via
previousReceiptHash(SHA-256 of the prior payload, JCS-canonical) - Produces a v2-envelope receipt @veritasacta/verify accepts natively (no verifier changes needed)
- Uses distinct issuer keys per layer:
scopeblind:seal:SB-SEAL-001for the sensor,sint:gateway:refusal-gateway-001for the gateway refusal — auditors can filter byissuer_idwithout introspecting payload - Deterministic (seeded key derivation + fixed timestamps) so fixtures are byte-reproducible
examples/physical-attestation-governed/policies/sint-physical-constraint.yaml— the declarative constraint envelope. Covers temperature, geofence, shock, and human-proximity (with theDynamicEnvelopePluginmapping you pointed at). Cedar-compatible rules noted inline so the future cedar-engine integration is a drop-in.examples/physical-attestation-governed/examples_output/wine-shipment-refusal-chain.bundle.json— reference output: 2-receipt chain (upstream reading + SINT refusal).Verifier round-trip, exit-0 gate-green:
$ npx @veritasacta/verify wine-shipment-refusal-chain.bundle.json --bundle ✓ Bundle: VALID Total: 2 Passed: 2 Failed: 0 # Tamper test: flip decision "refuse" -> "allow" in-place and re-verify $ npx @veritasacta/verify wine-shipment-refusal-chain.TAMPERED.bundle.json --bundle ✗ Bundle: INVALID Total: 2 Passed: 1 Failed: 1 Errors: • Receipt 2: invalid_signature # exit 1Three things worth flagging for your SINT-side code:
-
v2 envelope, signature over envelope-minus-signature. The original merged
getting_started.pyusesHS256-DEMOand signs only the payload — that's demo-only and does not verify via@veritasacta/verify. The production path signs the whole envelope (minussignaturefield), JCS-canonicalized, Ed25519. I followed the@veritasacta/artifactsreference implementation exactly. If your SINT runtime already emits a different shape (e.g. the Revettr-style{provider, subject, attestation, jws, sibling}wrapper AlexanderLawson17 is using), the cleanest path is a standalone v2 receipt alongside the full envelope — the verifier then exits 0 on the standalone without any wrapper-shape changes. -
RFC 8785 number serialization is load-bearing. Python's default
json.dumpspreserves trailing.0on whole-number floats (38.0stays"38.0"), but JSJSON.stringifystrips it ("38"). If your SINT code emits floats, you need to collapse whole-number floats to integers before canonicalizing, or use an rfc8785 library. I added a one-function normalization helper inline (_normalize_numbers) so the demo needs only pynacl, no rfc8785 dep — worth copying or replacing with rfc8785 depending on your preference. -
Key derivation is seeded for fixture reproducibility, not for production. In a real SINT deployment the gateway key lives on an HSM or secure element — the
derive_key()helper here is purely to make the example's receipts byte-identical across runs. Replace with your actual gateway key handling when wiring to the live SINT runtime.
What this leaves for your diff:
- Swap
build_upstream_cold_chain_receipt()for your live SINT→upstream-receipt adapter (your gateway reads the real sensor receipt from the bridge-iot message path; my stub is just reading build(deps-dev): Bump underscore from 1.13.7 to 1.13.8 in /packages/agent-os/extensions/cursor #5 from the merged journey). - Wire
build_sint_refusal_receipt()into theDynamicEnvelopePlugin.evaluate()path, so a refusal decision emits a receipt in-line with the plugin return value. - Replace the seeded
SINT_GATEWAY_KEYwith the gateway's real signing key. - (Optional) Add more constraint kinds beyond
temperature_excursion—geofence_breach,shock_excursion,human_proximityare all scaffolded in the YAML policy.
Tymofii Pidlisnyi (@aeoess) the
external_receipts.apsslot convention from VeritasActa/verify#2 applies here too — an APSDecisionLineageReceiptfor the delegation that authorized the wine-shipment release would chain cleanly into this bundle under the sameku_id-equivalent key. If you want to dropaps_delegation_wrapper.pyinto the same folder, the receipt envelope shape is compatible and the bundle'sverification.signing_keysarray takes your JWK without schema changes.Standing by on your SINT-side runtime integration. Happy to PR the skeleton into the AGT repo as a follow-up to #1168 once you confirm the shape works for your evaluation path — or you can absorb it into your own branch, whichever is cleaner for the MSFT review.
- Chains onto an upstream cold-chain reading receipt via
The skeleton is solid. Two-receipt chain with distinct issuer keys per layer (
scopeblind:seal:SB-SEAL-001for the sensor,sint:gateway:refusal-gateway-001for the gateway refusal) is the right design — auditors can filter byissuer_idwithout introspecting payload, and the per-layer key rotation story stays clean.For the APS-side composition slot: the
sint:gateway:refusal-gateway-001layer is where an APSgovernance_attestationwould naturally bind. The SINT gateway holds the enforcement capability; the APS attestation binds that enforcement capability to the upstream delegation chain (who authorized this SINT gateway to refuse on this principal's behalf, under what scope, with whatskill_creationoractuator_classaxes). That's the three-layer composition the APS-SINT-MCP handshake spec (now shipped atdocs/specs/aps-sint-handshake-v1.mdper sint-ai/sint-protocol#109) formalizes.Concrete: an APS Governance Attestation receipt chained into the upstream position in this bundle (before the cold-chain reading) would close the "authority to refuse" question. The bundle becomes a three-receipt chain (APS governance attestation → cold-chain reading → SINT refusal), each Ed25519-signed, each chaining via
previousReceiptHash, each with a distinct issuer key. Happy to draft that third receipt as a drop-in once the SINT-side integration lands and the fixture has a stable shape. Flagging as available for pshkv's next iteration.Illia Pashkov (@pshkv) — the two-evening turnaround on this is impressive and the receipt shape maps cleanly to the SINT v2 physical constraint work you're doing elsewhere. The skeleton plus the AAIF submission tracking on sint-ai/sint-protocol#130 gives the three-vendor governance_attestation story (APS + SINT + MolTrust) a concrete physical-AI worked example to cite. Worth including this bundle as an evidence pointer in the AAIF submission packet.
Strong framing. The four gaps you identified (physical constraint model, environment-adaptive constraints, irreversibility tier system, swarm collective constraints) map cleanly onto work already underway in AGT-adjacent repos:
examples/physical-attestation-governed/(feat(examples): physical-attestation-governed — cold chain sensor receipts #1168, merged) shows the decision-receipt half of this: a simulated cold-chain sensor emits Ed25519-signed readings that a governance policy evaluates and signs as a decision.aeoess/agent-governance-vocabulary#34(currently in review, signing it off shortly) introducesphysical_environment_stateas a canonical context dimension with explicit replay-class semantics for sensor-attested values.- SINT Protocol is cited in your issue as the reference execution layer for MAVLink / ROS 2 bridges.
Proposing a three-piece contribution if the scope suits the maintainers:
-
Tutorial 34: Physical Agent Attestation. Demonstrates sensor-derived policy context using ATECC608B and SE050 reference hardware examples. Pairs with Tutorial 33 (decision receipts) as the hardware-anchored variant. Would cover arming-tier decisions emitting verifiable receipts before execution rather than post-hoc audit.
-
PhysicalConstraintPolicyCedar schema extension. Velocity, force, geofence as first-class policy inputs rather than free-form attributes. Lives inpackages/agent-hypervisor/. Interoperates with AGT's existing Cedar evaluator without modification. -
Irreversibility tier specification. Formalized as either an ADR or a proposal doc depending on maintainer preference. Distinguishes pre-action authorization (human-in-the-loop for Tier-4 actions like arming/movement) from post-action audit (Tier-1/2 logging-sufficient decisions), with the dividing line written into policy rather than each operator's convention.
Illia Pashkov (@pshkv), happy to coordinate with the SINT side so the two codebases converge on shared policy schema rather than diverging. You're already collaborating on the vocabulary work; a natural next step might be a joint ADR or proposal covering both the
PhysicalConstraintPolicyschema on AGT's side and the MAVLink/ROS 2 execution bridge SINT defines. That lets each codebase own its layer (policy vs execution) while the contract between them is written once.Happy to wait for maintainer feedback on scope before opening PRs. Cc Imran Siddique (@imran-siddique) for scoping input.
Good news — we shipped a physical attestation example: \�xamples/physical-attestation-governed/\ with a cold-chain sensor scenario. It demonstrates AGT governance for physical agent actions (temperature monitoring, actuator controls).
The OWASP coverage gap for robotics/actuator systems is real — our current mapping focuses on digital agents. We'd welcome a contributed mapping document under \docs/compliance/\ that extends the OWASP coverage to physical systems.
Keeping open for the compliance mapping contribution.
Reacted by TJFGood progress here. The physical attestation governed example (examples/physical-attestation-governed/) shipped and demonstrates AGT governance for physical agent actions. The OWASP compliance mapping for physical systems is a welcome contribution as a docs PR under docs/compliance/ if anyone wants to pick it up. Closing this out. Thanks Illia Pashkov (@pshkv) for raising the physical agent gap and the detailed SINT Protocol reference.
- added a commit that references this issue
on Jun 1, 2026
The toolkit covers the software agent security surface well. Opening this to discuss a gap that the current seven packages don't address: physical AI agents — LLM-driven systems that actuate in the real world via ROS 2, MAVLink (drones), industrial controllers, or embedded hardware.
Why physical agents require additional governance primitives
Software agents that go wrong can be rolled back. Physical agents that go wrong cause irreversible harm — a drone that arms without authorization, a robot arm that exceeds safe velocity near a human, a welding robot that actuates without human sign-off.
The OWASP Agentic Top 10 framework covers these conceptually but the enforcement mechanism is different:
Specific gaps in the current toolkit
No physical constraint model — There's no equivalent of
maxVelocityMps,maxForceNewtons, or geofence in the policy schema. Physical agents need these as first-class constraints, not just action allow/deny.No environment-adaptive constraints — Static policy rules can't adapt to real-time sensor state. An obstacle at 0.4m should automatically cap velocity to 0.1 m/s regardless of what the token says. This requires a plugin interface that runs on every action, not a static policy file.
No tier-based irreversibility model —
ARM + MISSION_STARTon a drone is categorically different from a sensor read. The governance layer needs to know that some actions are physically irreversible and require explicit human sign-off before execution (not audit after).No swarm collective constraints — Per-agent governance doesn't capture emergent collective risk. A fleet of individually-authorized drones can collectively exceed safe kinetic energy limits.
What we've built as a reference
SINT Protocol is an open-source physical AI authorization layer that covers exactly this surface:
T0_observe → T1_prepare → T2_act → T3_commitmapped to reversibility + physical riskmin(token.maxVelocityMps, obstacle_distance × reaction_factor)per action950 tests across 18 packages.
Proposal
Happy to collaborate on:
PhysicalConstraintPolicyschema extension foragent-osbridge-mavlink/bridge-ros2and the AGT policy engineIs physical AI in scope for the toolkit's roadmap? Would the team be open to an integration PR?