[Carlos Hernandez (carloshvp)]

Summary

• add a physical-agent profile to the canonical OWASP ASI compliance page
• map ASI01-ASI10 to physical-system failure modes, applicable AGT controls, and residual safety requirements
• define the boundary between AGT software governance and an independent physical safety controller
• document the evidence and limitations of the shipped physical-attestation example
• clarify that the official 2026 OWASP list contains ASI01-ASI10 and that AGT traceability is a project-specific extension

Why

Issue #787 identified that AGT's existing OWASP mapping focused on software-only agents. After the physical-attestation example shipped, the maintainer explicitly invited a compliance mapping under docs/compliance/ for robotic and actuator systems.

This profile shows how AGT can govern the software decision path before a physical command while keeping hardware interlocks, emergency stops, collision avoidance, and real-time safety controls outside AGT's scope.

Scope

Documentation only. This PR does not add robotics middleware, actuator control, hardware safety primitives, or a new roadmap commitment.

Validation

• python3 scripts/docs/check_links.py
  • 0 new broken links; 170 baselined
• python3 scripts/docs/check_frontmatter.py
  • changed page has no finding; repository-wide pre-existing warnings remain
• CI-equivalent cspell check on added lines
  • 0 issues
• python3 examples/physical-attestation-governed/getting_started.py
  • 8 readings evaluated; 3 policy violations identified; simulated tampering detected
• git diff --check

References

• Follow-up to Physical AI agents: OWASP coverage gap for robotic/actuator systems #787
• OWASP Top 10 for Agentic Applications for 2026

Type of Change

• Documentation update

Package(s) Affected

• docs / root

AI Assistance

• I can explain every meaningful change in this PR: what it does, why, and what tradeoffs were considered
• I have run tests and verification appropriate for this change
• No part of this PR was autonomously submitted by an AI agent without my review
• I have not used AI to generate review comments on others' PRs

Codex assisted with repository analysis, drafting, and validation; all output was reviewed and validated.

IP, Patents, and Licensing

• This contribution does not implement patent-pending or patent-encumbered techniques
• This contribution does not require an NDA or licensing agreement to understand or use
• Any AI tools used have terms compatible with the MIT License

[github-actions]

PR Review Summary

Check	Status	Details
🔍 Code Review	⚠️ Missing	No current-run comment
🛡️ Security Scan	⚠️ Missing	No current-run comment
🔄 Breaking Changes	⚠️ Missing	No current-run comment
📝 Docs Sync	⚠️ Missing	No current-run comment
🧪 Test Coverage	⚠️ Missing	No current-run comment

Verdict: ⚠️ AI review incomplete; ready for human review

AI review comments are untrusted advisory output. The summary reports workflow-generated completion status only, not model-authored pass/fail claims.

[Ricky Gummadi (Ricky-G)]

Nice work on this, Carlos Hernandez (@carloshvp)! The taxonomy correction (ASI01-ASI10 official, AGT Extension for traceability), the control boundary diagram, and the honest shipped-evidence limits section are all well done. Thanks for taking this on.

One minor thing to consider:

In the physical risk mapping table, the ASI04 row describes an applicable AGT control as: AGT release workflows generate and attest software SBOMs. The software section of the same document still carries a Known Gap note saying No SBOM generation or dependency vulnerability scanning is built into AGT. These refer to different things (CI/release-pipeline SBOMs vs. AGT as a product generating SBOMs for governed agents) but a reader scanning both sections could find them contradictory. A short qualifier like for AGT own release pipeline in the physical table row would make the distinction clear.

Totally fine to address as a quick follow-up if you prefer to keep this PR minimal.

[Imran Siddique (imran-siddique)]

The changes are accurate, well-scoped, and technically honest. The taxonomy correction (ASI01–ASI10), the Mermaid boundary diagram, the risk table, and the "Shipped Evidence and Limits" section are all sound. Approving with one fix request and one optional suggestion.

Fix before merge

Line 226 in the existing ASI10 section still cites agent-governance-python/agent-os/src/agent_os/services/behavior_monitor.py — that path does not exist. The new physical risk table in this PR correctly uses agent-governance-python/agent-mesh/src/agentmesh/services/behavior_monitor.py. Since this file is already being touched, please correct the stale citation to keep the doc internally consistent.

Optional suggestion

The deployment checklist doesn't address governance-service unavailability in physical deployments. A stalled policy evaluation blocking an actuator is a more acute safety scenario than the equivalent software case. Worth adding one checklist item:

Test governance-unavailable behavior — ensure a stalled policy evaluation triggers a safe stop, not a permitted actuator command.

This is already alluded to in LIMITATIONS.md §10; surfacing it in the checklist would close the loop.

[Imran Siddique (imran-siddique)]

CI green, changes addressed — merging.