PALO FRAMEWORKEuropean delegated-action governance profile#
PALO discussion specification v0.2 | 22 September 2026 | Proposed functional profile, not an EU standard.
Scope and terminology#
This profile supports the policy proposal. It covers AI-assisted selection, initiation or delegation of operations that affect external systems, resources or people. It is technology neutral and does not change legal risk classification. A mandate is a recorded operational grant, not a conclusion about legal agency or liability. An accountable owner is a named human or organisational role with actual authority and resources to supervise the deployment.
The review boundary must include the model, orchestrator, tools, credentials, memory, relevant external resources and observation services. Record excluded paths explicitly. An API wrapper is not an enforcement boundary when the agent can reach the same resource using other credentials.
Twelve proposed control objectives#
| ID | Objective and minimum evidence | Acceptance test | Existing PALO correspondence |
|---|---|---|---|
| DAG-01 | Identify system, accountable owner, responsible legal actors and assessment boundary | No owner or unresolved boundary prevents evaluation admission | AI system record; PALO Case File |
| DAG-02 | Bind an expiring mandate to verified workload identity and versioned scope | Expired, unknown or wrong-tenant authority is rejected | Agentic interface; identity-bound Action Claim |
| DAG-03 | Narrow child permissions and preserve ancestry | A child cannot acquire a new tool, data purpose or greater limit | Agent profiles; unreleased swarm membership |
| DAG-04 | Bind purpose, data fitness, recipients and egress conditions | Stale fitness or unapproved recipient stops the action | Data Fitness Decision; Disclosure Contract |
| DAG-05 | Evaluate exact action arguments and policy at the execution boundary | Mutation after decision or an attempted bypass fails | Action Claim; execution capability; governed executor |
| DAG-06 | Require prior human approval for consequential actions with absent or unproven reversibility | Missing, expired or changed-action approval blocks dispatch; other denial conditions remain binding | Approval digest and role checks; strengthened profile rule requires implementation tests |
| DAG-07 | Enforce aggregate exposure and concurrency in one defined authority domain | Concurrent agents cannot exceed the reserved common budget | Unreleased shared-budget swarm prototype |
| DAG-08 | Prevent replay and handle uncertain execution without blind retry | Reusing a consumed capability does not repeat the external effect | Single-use capability; execution intent |
| DAG-09 | Revoke future work and distinguish in-flight containment states | Removed member cannot start; unsupported stop remains unsupported | Swarm revocation; cancellation verifier prototype |
| DAG-10 | Observe outcome separately from execution acknowledgement | Missing observation yields unknown/inconclusive, not verified | Effect Contract; outcome attestation |
| DAG-11 | Preserve evidence origin, integrity, access and minimisation | Tamper detected; stale or untrusted evidence rejected; excessive payload flagged | Evidence Envelope; disclosure minimisation |
| DAG-12 | Reassess change, contain incidents and support remedy | A new tool or unresolved mismatch opens review and holds affected work | Assurance signals; incident lifecycle; governance gates |
These are proposed profile requirements. The source mapping to legal provisions is in the policy dossier. No existing law is described as mandating these exact identifiers or a PALO implementation.
Formal invariants#
For a delegation edge from parent p to child c:
Allowed(c) ⊆ Allowed(p); Expiry(c) ≤ Expiry(p); Purpose(c) ⊆ Purpose(p).
These sets represent the effective intersection of all ancestor constraints, not an arbitrary comparison of JSON text. General schema containment is not assumed decidable by a simple validator. The reference swarm implementation restricts inherited argument schemas rather than claiming general logical implication.
For a proposed action a at time t:
MayStart(a,t) = identity_valid ∧ mandate_current ∧ policy_allows ∧ evidence_fresh ∧ approval_satisfied ∧ exposure_reserved ∧ capability_unspent ∧ connector_admitted.
A missing conjunct cannot be treated as true. Revocation and mandate revisions must be checked again immediately before the controlled effect. A positive decision is an authorisation statement, not an outcome statement.
For a shared budget B in the declared authority domain:
committed_exposure + reserved_exposure ≤ B.
Reservation and consumption must be atomic with respect to competing starts. Separate ledgers cannot each assume the whole budget. An uncertain external result retains exposure until authoritative reconciliation or an explicitly governed correction. Financial amounts require exact units and currency; integer minor units are preferable to binary floating-point comparisons.
For verification:
Verified(a) ⇒ trusted_observation(a) ∧ expected_effects_hold ∧ forbidden_effects_absent_within_observed_scope.
Verification remains limited by the observation boundary. No observation can establish the absence of every unobservable side effect. Evidence signing supports provenance and integrity but cannot convert a dishonest or incomplete observation into truth.
Pre-dispatch approval for consequential irreversible actions#
Before evaluation, the accountable owner and evaluator must agree the consequence classes, reversibility evidence and applicable prohibitions. The executing agent cannot downgrade its action class or treat an unknown effect as reversible.
Within the declared scope, a materially consequential action that is irreversible, or whose reversibility has not been established, must not be dispatched without prior approval by an authorised human. Approval binds the exact action, target, material parameters, expected effects, limits and expiry. Material changes invalidate approval. Missing or expired approval blocks dispatch. Approval does not override a prohibition, absent authority or any other denial condition. If meaningful review cannot be provided, keep the action blocked or redesign the workflow.
Consequential(a) AND (Irreversible(a) OR ReversibilityUnknown(a)) => PriorHumanApprovalRequired(a).
This is a proposed profile rule, not a universal interpretation of Article 14 or a claim about current PALO runtime enforcement. Safety-critical situations where delay itself creates a hazard need a separately justified control design and sector analysis; the agent cannot grant itself an emergency exception.
Compensation is a new, separately authorised action intended to address consequences. It does not establish restoration of the original state or erase the incident. Reversible low-impact actions may operate within an approved bounded mandate, but preventive authorisation, logging and outcome checks still apply. Post-hoc review does not replace those controls.
The supplementary approval tests cover missing approval, unknown reversibility, changed or expired approval, other denial conditions, compensation and emergency self-exemption. All are proposed tests marked NOT RUN. An implementation must demonstrate the rule before claiming coverage.
Evidence chain and trust boundaries#
- Register: legal actors, owner, workload identities, tools, resources and verifier identities.
- Mandate: sign or otherwise protect purpose, permissions, limits, expiry and delegation scope with an auditable issuing authority.
- Claim: bind action, arguments, context, policy version, mandate version and expected effects.
- Decide: evaluate current evidence; return deny, request approval or permit under defined conditions.
- Approve: when required, including the consequential irreversible-action rule above, show the actual target, effects, limits and expiry to an authorised human; bind the approval to the exact claim.
- Execute: enforce at the resource boundary; consume authority once and preserve execution identity.
- Observe: obtain separate pre/post evidence where appropriate, from an authoritative resource or a justified observation mechanism.
- Reconcile: record verified, mismatch or inconclusive; retain uncertainty, open incidents and manage compensation separately.
The model is not trusted to grant itself authority. Untrusted retrieved content is data, never a mandate amendment. Tool credentials belong to the controlled execution boundary. Verifier identities and permissions should be separated from executors where feasible; administrative separation alone is not independent assurance.
Evidence records should bind identifiers and digests for system, deployment, mandate, action, policy, approval, execution and outcome; timestamps with clock assumptions; source and signer; applicable expiry; schema version; and review status. Existing PALO contracts remain authoritative for their own formats. The new EU review schema is a reviewer inventory, not a replacement execution envelope or a signed attestation.
Intervention and failure semantics#
| Event | Required interpretation |
|---|---|
| Policy service unavailable | Do not infer permission. Use the predefined safe state for the operation; emergency procedures need separately defined authority. |
| Request timed out after dispatch | Execution may have occurred. Hold and reconcile before any retry. |
| Revocation before start | Prevent new execution within the controlled boundary and invalidate unspent authority. |
| Stop requested during execution | Record requested until authoritative confirmation. |
| Confirmed cancellation | State the observed absence of effects and observation time, within the specific connector's guarantees. |
| Irreversible effect already committed | Record too late; consider a separately authorised compensating action and affected-person remedy. |
| Partition, compromised verifier or missing evidence | Record unknown/inconclusive and escalate; do not fabricate a clean result. |
A compensation attempt is not proof that an irreversible effect was undone. No generic kill switch is assumed to stop an arbitrary third-party system. Emergency availability and safety tradeoffs must be analysed per deployment.
Proportionality profiles#
Observe-only: a tightly bounded, read-only system with no consequential external action may use a lightweight inventory, purpose/access controls, minimised logs and a review owner. Read access can still expose sensitive data and needs a contextual assessment.
Bounded action: allowlisted reversible actions add expiring authority, action binding, outcome checks and escalation. Reversibility is a tested property of the target operation, not an agent's promise.
Consequential or composed action: material effects, subdelegation, shared resources or difficult reversal require stronger identity, cumulative controls, intervention drills, independent observation and change management.
Unknown reversibility cannot qualify an action for the bounded reversible-action profile. These are engineering profiles, not AI Act risk tiers. No score from the workbench determines legal classification. Additional legal obligations may apply at every profile.
Operational review tool#
The site workbench asks for a system, owner, context, reviewer and evidence state for all twelve controls. Evidence states are missing, claimed, reviewed or not applicable. Reviewed items need a reference and named reviewer; not-applicable items need a justification and reviewer. Those fields are assertions by the operator and still need substantive review.
Version 0.2 strengthens DAG-06. Version 0.1 inventories require a fresh review and are not silently upgraded on import. The export includes the immutable proposal version, source-review date, explicit non-certification status, entries and unresolved questions. A bundled JSON schema and dependency-free validator test structure and the completeness of review declarations. They do not fetch evidence, verify signatures, execute an agent or assess legal adequacy. A separate CSV test plan identifies expected outcomes and observation requirements.
Current implementation boundary#
PALO-AI remains a developer preview. The unreleased swarm extension coordinates remote workers through a central authority and SQLite ledger. It does not provide replicated authority, controller failover, managed key custody, arbitrary connector cancellation or independent production assurance. Test passes demonstrate only the tested fixtures and boundary. See the capability matrix and swarm implementation documentation.
Before any production recommendation, independently examine credential custody, tenant isolation, resource-level enforcement, recovery, retention, access controls, external-effect observation, incident operations and human intervention. Document alternative implementations and compare them under the same evaluation protocol.