K05 assurance architecture
Multi-agent trust boundaries
Direct answer
Authenticate agent-to-agent messages, isolate memory and tools, limit propagation depth, and treat peer output as untrusted evidence rather than authority.
Evidence boundary. These records describe architecture, control relationships, test requirements, and legal-source status. They do not certify a facility, authorize a mission, prove deployment, or replace current facility-specific engineering and legal review.
Objective
Authenticate agent-to-agent messages, isolate memory and tools, limit propagation depth, and treat peer output as untrusted evidence rather than authority.
Implementation evidence
- approved design and scope
- exact configuration or policy artifact
- test result
- defect and exception record
- operating observation where deployment is claimed
- last review and evidence owner
Evidence of failure or insufficiency
- missing or stale artifact
- control bypass
- unresolved defect
- scope mismatch
- unsupported compliance label
- unavailable operating evidence
Qualified source mappings
- NIST SP 800-82 Rev. 3 — INFORMSOT security program, architecture, risk, and control guidance
Applies as guidance when OT is in scope; Revision 3 remains final while Revision 4 is under development.
Source record - NIST SP 800-207 — INFORMSZero Trust Architecture principles
Applies to identity- and resource-centric access design; does not replace OT safety analysis.
Source record - INL Consequence-driven Cyber-informed Engineering — INFORMSConsequence prioritization and critical-function assurance
Useful for high-consequence pathway analysis; not a regulatory certification.
Source record
Assurance claims
Authority boundary. Control design and mapping do not create mission authority, license approval, certification, or universal applicability.