ADR-0001: Separate AI Reasoning from Execution Authority¶

Status: Accepted
Date: 2026-08-01
Decision Owners: VND TECH LLC
Reviewers: Public architecture maintainers
Related Documents: ../ARCHITECTURE.md, ../GOVERNANCE.md, ../THREAT_MODEL.md

Context¶

AI systems can interpret instructions, generate plans, select tools, retrieve information, and propose actions. These capabilities create value, but they also create a security and governance risk when the same system is permitted to execute real-world actions without an independent authority check.

Model capability does not establish that:

The requester is authorized.
The requested action is within scope.
The target system may be accessed.
Required approvals have been obtained.
The action complies with policy.
The execution environment is safe and ready.

A compromised, manipulated, misconfigured, or simply mistaken AI system may produce an action that is technically possible but not authorized.

Decision Drivers¶

Prevent model capability from becoming implicit authority.
Preserve least privilege.
Support fail-closed execution.
Enable independent policy evaluation.
Support human approval for consequential actions.
Generate attributable evidence for decisions and execution.
Limit the impact of prompt injection, connector abuse, and excessive agency.

Considered Options¶

Option 1: Direct Model-to-Tool Execution¶

The AI model may invoke tools or connectors whenever it determines that execution is useful.

Advantages

Low latency.
Simple implementation.
Fewer architectural components.

Disadvantages and risks

Model reasoning and authority are conflated.
Prompt injection may directly influence execution.
Policy bypass is difficult to prevent reliably.
Evidence and approval may be incomplete or inconsistent.
Least-privilege enforcement becomes fragile.

Option 2: Model-Self-Governed Execution¶

The model evaluates its own authority and policy compliance before using tools.

Advantages

More flexible than direct execution.
May reduce implementation complexity.

Disadvantages and risks

The same component proposes and authorizes the action.
Model error or manipulation may affect both reasoning and control.
Decisions are difficult to verify independently.
Fail-closed behavior cannot be guaranteed by model instruction alone.

Option 3: Independent Pre-Execution Governance Boundary¶

The AI system proposes a structured action request. Independent components validate identity, authority, policy, risk, approval, capability scope, and runtime readiness before execution.

Advantages

Separates capability from authority.
Supports least privilege and fail-closed behavior.
Enables independent policy and approval controls.
Produces stronger evidence and audit records.
Reduces the consequences of model manipulation or error.

Disadvantages and risks

Adds architectural complexity.
May increase latency.
Requires consistent interfaces and evidence handling.
Governance services themselves become critical security components.

Decision¶

AegisLayer adopts an independent pre-execution governance boundary.

AI models and agents may propose actions, but they do not receive implicit authority to execute those actions. Before execution, the system must independently evaluate:

Identity and request origin.
Delegated or direct authority.
Structured intent, target, and scope.
Applicable policy and contextual risk.
Required human or multi-party approval.
Connector compatibility, health, and readiness.
Capability limits and credential scope.
Runtime constraints and evidence requirements.

Only after those conditions are satisfied may a constrained, time-limited capability be issued to the controlled execution runtime.

Security and Governance Analysis¶

Identity and Authority¶

The requester, agent, service, and delegated authority must be validated independently of the model's own assertions.

Policy Enforcement¶

Policy evaluation occurs outside the reasoning model and before external execution.

Human Approval¶

Consequential, exceptional, or high-risk actions may require explicit approval bound to a specific request, target, scope, and validity period.

Capability Scope¶

Execution receives only the minimum capability required for the approved action.

Connector and Tool Access¶

Connectors are not exposed as unrestricted model abilities. Access is mediated through registry, compatibility, health, routing, credential, and runtime controls.

Evidence Generation¶

The request, authority context, policy decision, approval, capability issuance, execution events, and outcome must be recorded with correlation and integrity metadata.

Monitoring and Incident Response¶

Capabilities may be revoked and execution may be cancelled or contained when context changes, anomalies appear, or policy violations occur.

Failure Behavior¶

Missing or unverifiable identity, authority, approval, policy state, connector readiness, or runtime state results in denial or escalation rather than silent continuation.

Consequences¶

Positive Consequences¶

Stronger separation of duties.
Reduced risk of unauthorized autonomous execution.
Better resistance to prompt injection and excessive agency.
More consistent evidence and auditability.
Clearer responsibility boundaries.
Greater ability to contain compromised components.

Negative Consequences¶

More components and interfaces must be maintained.
Execution may take longer due to validation and approval steps.
Governance services require high availability and strong protection.
Policies and authority models must be kept current.

Residual Risks¶

Independent controls may still be misconfigured or compromised.
Incorrect policy or authority data may produce incorrect decisions.
Approved actions may still have unexpected downstream effects.
Third-party systems may behave unpredictably after invocation.

Validation and Acceptance Criteria¶

This decision is satisfied when the public architecture consistently shows that:

AI reasoning produces a proposed action rather than direct authority.
Identity and authority are independently validated.
Policy evaluation occurs before external execution.
Approval is required where risk or governance rules demand it.
Runtime execution is capability-scoped and time-bounded.
Evidence is generated across the full request lifecycle.
Missing trust conditions fail closed.

Rollback or Reconsideration Conditions¶

This decision should be reconsidered if:

A materially safer and independently verifiable execution model becomes available.
New regulatory or operational requirements demand a different authority model.
Evidence demonstrates that the control boundary creates unacceptable risk or prevents required operations.
The architecture changes so substantially that the current separation no longer describes the system.

Public-Release Review¶

This ADR does not disclose credentials, customer information, confidential infrastructure, proprietary production controls, or unapproved patent-sensitive implementation details.

References¶

../ARCHITECTURE.md
../GOVERNANCE.md
../THREAT_MODEL.md
../DIAGRAMS.md

Change History¶

Date	Change	Author
2026-08-01	Initial accepted decision	VND TECH LLC