One treats security as a linked semantic and operational proof rather than a collection of framework annotations.
Four distinct links
requirement -> grant -> runtime token -> host enforcement- A requirement states what a selected realization needs.
- A grant is an approved authority decision for a principal and scope.
- A runtime token carries short-lived, bounded authority.
- Host enforcement gates the actual filesystem, network, secret, device, provider, or imported capability.
No link substitutes for another.
Capabilities are typed
A capability has identity, version, operations, resource scope, delegability, enforcement mappings, and observation policy. It is not a Boolean feature or an ambient service locator.
Local calls, remote calls, build tools, provider code, browser workers, AI principals, and deployment controllers use the same authority laws.
Effects constrain permission
Pure, read, disclose, write, delete, compensatable, and irreversible behavior carry different approval, retry, audit, and reconciliation obligations.
An effect declaration is not permission. It informs planning and policy so an appropriate grant can be issued.
Secrets remain references
Secret bytes do not enter semantic declarations, generated clients, plan explanations, or shared caches. A plan carries an exact secret reference and scope; the selected runtime resolves it only under the corresponding grant and host enforcement.
Secret-derived artifacts are explicit non-shareable build actions with separate provenance.
AI is an ordinary principal
AI can propose source, plans, or actions. It uses the same identity, policy, capability, approval, and audit path as deterministic tools. It receives no hidden authority and cannot turn a proposal into trusted IR or application.
Trust is evidence
Publisher claims, package attestations, tool admission, provider conformance, artifact signatures, and runtime identity remain distinct evidence. A self-reported digest or successful probe does not prove independent trust.
Canonical owner: Authority.