Security Model
Forge's security model is not an afterthought layered around the runtime. It is part of the runtime contract.
Enforcement layers
- boundary contracts define what an agent may do
- Aegis verifies delegation and authority flow
- Arsenal constrains capability and credential use
Each layer answers a different question:
- boundary contracts: what actions are allowed
- Aegis: who legitimately authorized those actions
- Arsenal: what scoped capability or credential material may be used to carry them out
Coding-provider execution
External coding-provider execution is security-sensitive because providers may:
- run long-lived sessions
- execute code or patches
- trigger sub-agent loops
- touch tools, files, or networks indirectly
Forge therefore requires fail-closed checks before remote execution:
- network authority
- delegation authority where needed
- valid delegation chain
- scoped capability eligibility
Fail-closed rule
Forge does not begin remote execution and then decide whether the agent should have been allowed to do it. Authorization, delegation, and scope checks happen before the session begins.
Documentation rule
Security documentation must distinguish clearly between:
- approved target contract
- shipped runtime behavior
- future roadmap items
That distinction is part of the trust model. Public security docs are not allowed to use aspirational wording where a concrete guarantee is expected.
Design rule
No local CLI convenience path, session-token shortcut, or vendor SDK helper is allowed to bypass these layers in a production Forge integration.