PALO-AI v2.5 — Full-Cycle Agentic Assurance#

Developer preview. Use synthetic or isolated data and non-consequential tools only. This implementation is not an independently assessed security boundary, compliance certification, production identity service or universal exactly-once executor.

Why the cycle extends beyond authorization#

A policy can determine that an action is permitted. It cannot prove that the action was correct, that the state observed by the agent was current, or that the external system produced the intended result. PALO-AI v2.5 therefore separates permission from assurance:

Propose → Authorize → Approve → Capability → Execute → Receipt → Observe → Verify → Escalate

An action is verified only when a registered verifier observes authoritative post-state that satisfies the immutable Effect Contract. A policy decision by itself remains allowed, not verified.

Contracts#

The Effect Contract uses a closed predicate DSL. Paths are JSON Pointers and supported operators are exists, equals, unchanged, changedTo and deltaWithin. PALO never evaluates caller-provided JavaScript or arbitrary expressions.

Trusted runtime flow#

1. Normalize and validate Action Claim 1.2.
2. Revalidate profile, current policy, replay material, expiry and exact approval.
3. Resolve active executor and verifier manifests from the trusted registry.
4. Issue a signed capability bound to claim digest, decision, tenant, resource, executor and verifier.
5. Ask the verifier for authoritative pre-state and check Effect Contract preconditions.
6. Consume the capability once and persist execution intent before calling the connector.
7. Invoke the operator-provisioned executor with the immutable arguments and idempotency key.
8. Generate a signed Execution Receipt inside the trusted runtime.
9. Ask the verifier for authoritative post-state and evaluate intended and forbidden effects.
10. Persist the signed Outcome Attestation and append lifecycle evidence to the hash chain.
11. On mismatch or uncertainty, create an Assurance Incident and hold the resource until human resolution.

The reference Gateway also scans its transactional outbox at startup. An execution left in executing/pending beyond PALO_EXECUTION_RECOVERY_AGE_MS (default: 30 seconds) receives a signed unknown receipt, is classified as inconclusive, and is held for review. An execution with a durably recorded receipt but no attestation resumes post-state verification. Receipt persistence and its evidence append are atomic. A matching final state alone cannot prove that an unknown recovered connector call caused it. This is single-instance recovery, not distributed exactly-once execution.

Automatic rollback is intentionally excluded. A compensating operation must be represented as a new Action Claim with its own authority, policy, approval, execution and verification cycle.

REST interface#

Existing decision-only integrations may continue to call POST /v1/actions/verify with Action Claim 1.1 or 1.2.

Full-cycle clients use:

POST /v1/evidence is disabled by default and returns HTTP 410. It can be temporarily enabled with PALO_ALLOW_UNTRUSTED_EVIDENCE=true only for legacy isolated demonstrations. New clients must use governed execution so receipt and outcome evidence are generated inside the trusted boundary.

n8n experience#

Package n8n-nodes-palo-ai 0.2 contains two nodes:

• PALO Governance: the compatibility decision-only gate with Allowed, Approval Required and Denied outputs.
• PALO Governed Action: the full-cycle node with Verified, Review Required, Denied and Execution Failed outputs.

The Governed Action node is programmatic because it builds a canonical Action Claim and routes a multi-stage gateway result to four semantic outputs. It does not expose the protected target tool as an independent downstream branch. A workflow that retains another direct credential path can still bypass PALO and must not be described as governed.

Run the synthetic catalog demonstration#

Start OPA:

.tools/opa/opa run --server --addr=127.0.0.1:8181 \
  examples/policy-as-code/agent-delegation.rego

Start the isolated Gateway:

export PALO_OPA_URL='http://127.0.0.1:8181'
export PALO_GATEWAY_TOKEN='palo-demo-only-gateway-token-32-bytes'
export PALO_HMAC_KEYS_JSON='{"key-catalog-demo":"palo-demo-only-signing-secret-material-32-bytes"}'
export PALO_ENABLE_DEMO_CATALOG='true'
export PALO_EXECUTION_RECOVERY_AGE_MS='30000'
export PALO_DATA_DIR="${TMPDIR:-/tmp}/palo-assurance-demo-$(date +%s)"
npm run palo:gateway

Run a verified effect:

export PALO_GATEWAY_TOKEN='palo-demo-only-gateway-token-32-bytes'
npm run demo:hands-on -- --auto-approve

Restart the Gateway with a fresh PALO_DATA_DIR, then demonstrate the “authorized, but wrong” case:

npm run demo:hands-on -- --auto-approve --wrong-effect

The second run must end with an Outcome Attestation of mismatch, an open Assurance Incident and resourceHold: true.

For n8n, install package 0.2 and import examples/n8n-demo/PALO-AI-full-cycle-assurance-demo.json. When n8n runs in Docker, configure the PALO API credential with http://host.docker.internal:8787; otherwise use the reachable HTTPS Gateway URL. Resolve the first approval, then rerun the node in Resume Approved Action mode with the exact immutable claim and approval ID.

Migration from v2.4.1#

1. Leave existing Action Claim 1.1 decision gates unchanged.
2. Upgrade the n8n package from 0.1 to 0.2; the original node remains registered.
3. For each protected action, declare an Effect Contract and move to Action Claim 1.2.
4. Register an executor manifest and provision its handler inside the runtime operator boundary.
5. Register a separately trusted verifier capable of authoritative pre- and post-state reads.
6. Replace caller-submitted execution evidence with POST /v1/actions/execute.
7. Route mismatch and inconclusive outcomes to an accountable incident owner.
8. Treat every compensation or rollback as a new governed action.

Production boundary#

SQLite, shared bearer tokens, environment HMAC keys and in-process adapters are reference mechanisms. Production adoption requires workload identity, principal-level RBAC, KMS/HSM-backed signing, PostgreSQL and durable queues, tenant isolation, HA, backup and retention, rate limiting, connector attestation, observability, threat modelling, penetration testing and an independent cryptographic review.