Identity before execution
Bind the request to an application, environment, user context, and allowed capability set.
Security / explicit boundaries
Control what the system may cross.
Inspect boundary model ↓
Make identity, data scope, region, provider, and tool authorization visible in the execution path, with verified evidence attached to any certification or deployment claim.
Data and action path
The boundary should be part of the architecture.
Control model
Data before destination
Resolve region and provider boundaries before any model or tool receives scoped context.
Authorization before action
Keep tool permissions narrower than the workflow and attach the decision to the trace.
Evidence after completion
Retain policy version, resolved boundary, and action outcome for later review.
Security review questions
Where can context go?
Define the provider, region, retention, and redaction conditions that apply to each execution class.
What may a tool do?
Separate read, write, approval, and high-risk actions; deny by default when required context is absent.
Who may alter policy?
Review versions, environment promotion, emergency fallback, and rollback as operational controls.
No badge theater
Security claims require evidence.
Certifications, audit status, encryption guarantees, data residency, and deployment modes should be stated only beside current evidence and precise operating boundaries.