Zero Trust Execution
Zero trust execution means an agent’s instructions, identity or claim of success are never sufficient authority to act or advance work. Operations require explicit permission, and results must satisfy the applicable acceptance criteria.
The diagram shows mediated access: Nucleus checks authority for external operations, while the agent receives access scoped to its task.
An agent can follow the wrong instruction, misunderstand a task or produce an incorrect result. The execution model must account for those possibilities without relying on the agent to enforce its own restrictions.
Instructions and authority
Section titled “Instructions and authority”Skills tell an agent how to perform its task. Context supplies the information it needs. Neither grants permission to access a resource or perform an operation.
Authority belongs to a specific execution and its permitted operations. Reading an artifact, creating a finding and approving work are separate capabilities. Permission for one does not imply permission for the others, even when the same agent could describe all three in a prompt.
Content encountered during a task must be treated the same way. A document that asks the agent to deploy a change cannot grant deployment authority.
Enforcement boundaries
Section titled “Enforcement boundaries”Different controls address different parts of execution:
- Tool authorisation determines which operations the task may request and which resources those operations may affect.
- Execution isolation limits the files, processes and network resources reachable from the execution environment.
- Credential scope limits access to external systems, including operations performed outside Nucleus tools.
- Acceptance rules determine whether the resulting work can progress.
These controls must agree. Restricting a tool does not protect a resource if an unrestricted shell or credential provides another route to it. The isolation available depends on the execution environment; a tool grant alone is not a sandbox.
Authority during execution
Section titled “Authority during execution”Permission must remain valid when an operation takes effect. Starting an authorised task does not grant permanent access or authorise a later attempt to reuse its permissions.
Nucleus’s workflow tool authorisation binds operations to the current invocation and execution attempt, the declared tool scope and non-revoked authority. A previous successful authorisation is evidence of that operation, not permission for the next one. Missing or ambiguous authority prevents the operation from proceeding.
Revoking authority and stopping a process are separate actions. Backend controls can reject subsequent operations while the execution environment is still shutting down; process termination requires its own confirmation.
Evidence and acceptance
Section titled “Evidence and acceptance”An agent’s report is evidence to assess. It does not establish that a check passed, an artifact is approved or a workflow may advance.
Atomic workflows separate producing work from evaluating and accepting it. Deterministic checks assess mechanical requirements, agent evaluations apply judgement, and human gates reserve decisions that require a person. The workflow applies its routing rules to the recorded results.
For example, a task may have permission to edit code and submit an artifact while lacking permission to approve or deploy it. A report saying “all checks passed” cannot substitute for the required check evidence or approval.
Evaluation still has limits: a passing check covers what it tests, and an agent or human reviewer can miss defects. Zero trust execution makes authority and acceptance explicit; it does not guarantee correct software.
Governance and traceability
Section titled “Governance and traceability”Factory Governance defines the rules for access, acceptance and changes to the factory. Zero trust execution applies those rules at the boundaries where operations occur and results become accepted work.
Retaining the execution identity, applicable versions, evidence and approval history makes those decisions explainable. A later investigation can distinguish an incorrect result from excessive permissions, a missing check or an approval based on insufficient evidence.