PDP Guard Decision Plane

Physically and logically separates governance responsibilities between proposal systems (Reasoning) and decision systems (Governance) to prevent runaway behavior and unintended side effects.

1. Purpose

When an LLM performs both reasoning and execution decisions (tool use, external actions) inside a single autonomous loop, decision authority depends on opaque model state and becomes difficult to govern.

AIKernel separates these responsibilities to provide:

• Enforced role split: LLM returns proposals only; final decisions are made by IPdp.
• Centralized side-effect control: one policy evaluation point for API, DB, file, and outbound operations.
• Deterministic auditability: permit/deny evidence is recorded independently from probabilistic model behavior.

2. Theoretical Model: PDP / PEP / PIP

AIKernel adopts standard access-control concepts (XACML-style model):

• PEP (Policy Enforcement Point): execution engine that queries IPdp before action execution.
• PDP (Policy Decision Point): this document's focus; returns Permit / Deny / Indeterminate.
• PIP (Policy Information Point): provides external attributes for decisions (subject role, system state, resource classification).

3. Core Contracts

3.1 IPdp (Policy Decision Point)

• Responsibility: consume a Proposal and current Context, then return Decision (Permit / Deny / Indeterminate).
• Note: supports chained PDP composition (Chain of Responsibility).

3.2 IGuard

• Responsibility: final pre-execution checkpoint for content inspection (injection detection, sensitive-data leak prevention).
• Contract example: ValidationResult Inspect(IExecutionMessage message)

3.3 IToolAccessValidator and IToolPermission

• Responsibility: validate execution rights for a specific tool/function call.
• IToolPermission: execution permit with scope, expiry, and max-invocation constraints.

3.4 IToolSandbox

• Responsibility: isolate execution environment for side-effecting code/commands.
• Definition: sandbox is not an optional runtime flag; it is an authorization obligation attached to PDP decisions.

4. Decision Rules

• Separation principle: IThoughtProcess must not depend on internal IPdp logic, and IPdp must not depend on hidden reasoning state.
• Side-effect freeze: until explicit Decision.Permit is issued, all external side effects remain staged (no write/send/delete commit).
• Mandatory audit: every decision is recorded immutably with policy version and PIP attributes used at evaluation time.

5. Fail-Closed Rule

AIKernel governance always resolves to the safe side.

• Indeterminate denial: Indeterminate, timeout, or decision infrastructure failure yields Deny and pipeline halt.
• Sandbox enforcement: if IToolSandbox initialization fails, all related execution requests are invalidated.
• Unsigned policy invalidation: if policy artifacts (Markdown/JSON) are unsigned or signature-invalid, IPdp must not load them and must deny all requests.

6. Sequence Logic (Logical View)

1. AI Kernel receives a "delete file" proposal from the LLM.
2. PDP calls IToolAccessValidator and checks actor role against resource criticality.
3. Guard inspects the target path for injection patterns (for example ../).
4. Decision issues Permit only when all checks pass.
5. Executor performs deletion inside IToolSandbox.

Changelog

• v0.0.0 / v0.0.0.0: Initial draft
• v0.0.1 (2026-05-06): Version upgrade aligned with documentation guidelines