AGENTIC ENGINEERING / SECURITY
Security follows the boundary.
An agent integration must constrain authority, not merely describe a task.
Security dimensions
| Dimension | BOUND question |
|---|---|
| Authority | Who owns the decision and who may approve the result? |
| Scope | Which files, resources, repositories, or records may change? |
| Credentials | Which credentials are exposed, for what operation, and for how long? |
| Network | Which hosts or services are reachable from the execution context? |
| Execution | Which runtime, process, container, or sandbox contains the work? |
| Approval | Which actions require human or policy approval before execution? |
| Verification | Which evidence must exist before changes are accepted? |
Minimum bounded context
- Explicit mission and owning boundary.
- Allowlisted change surface.
- Named tools and dependencies.
- Credential scope appropriate to the task.
- Resource and network limits where applicable.
- Required verification commands or evidence.
- Clear escalation path when the requested change exceeds the boundary.
Forbidden inference
An agent should not infer authorization from visibility, repository access, tool availability, or successful authentication. Those are capabilities or facts about the environment; they are not substitutes for an explicit boundary and contract.
Future implementation target: machine-readable permissions, sandbox policies, approval rules, and verification gates can later be attached to BOUND artifacts. This page intentionally does not claim that such a runtime exists today.