Install PALO in a customer tenant: evaluation release 0.1.0-rc.1

Updated 28 October 2026 (Europe/Rome); recorded test runs are dated 27 October UTC. Distribution choice: customer-owned tenant and host. This guide configures the synthetic reference integration that has a completed bounded Azure/Copilot case. It does not qualify an arbitrary customer business system.

Download source archive · SHA-256 · Pilot evidence

This candidate is distributed under the MIT license; LICENSE is included in the archive manifest. Dependency licenses are recorded where available in the CycloneDX SBOM. This inventory is not a legal opinion, vulnerability scan or signed provenance attestation.

Release status: evaluation candidate, not production-ready. The demonstration agent remains private. No shared SaaS endpoint, managed-solution ZIP, Marketplace certification, paid SLA or automatic billing is included.

Recorded checks and their scope#

Both post-update test runs use the archive SHA-256 stated below. The test and source inventory lists the 107 gateway and 11 Python test names, source hashes, environment versions and log digests. The tests were run under the maintainer-directed workflow, not by an independent assessment organization. The catalog subset has 7 tests; it is not the authority test count.

The dependency updates address registry advisories affecting the bundled MCP SDK, Hono and Zod versions. The archive pins MCP client/server 2.4.0, MCP Hono 2.0.2, Hono 4.13.14 and Zod 4.6.7. The npm audit result covers the installed JavaScript dependency tree only. It does not inspect Python helpers, Node/Python runtimes, the operating system, unknown vulnerabilities or the PALO design. The failed source-scan startup remains an open security-assurance action before production. Release coordination belongs to Fabrizio Degni, with implementation tracking in this Codex release workstream; an independent assessment executor has not been appointed. No completion date is claimed. Until the review is completed, use an isolated evaluation host and synthetic data only. See the exact lockfile and MCP SDK security advisories.

The following operational checks were maintainer-directed on Azure Linux on 27 October 2026 UTC, using the exact archive hash below; they are not third-party reproductions. The live runtime was upgraded with that source bundle. Post-upgrade checks preserved price 120/version 2, one write, one execution, all approval records, keys and mandates. Anonymous access to both protected routes returned 401. The reviewer script served over HTTPS matches the qualified file hash. A private backup was restored into a distinct directory: all 12 archived files matched, authority was empty and the live state was not replaced. These checks do not establish customer RPO/RTO.

The completed authenticated Copilot mutation/replay case ran on the preceding pilot revision. This candidate adds the reviewer correction, dependency updates and portable packaging. Its post-update evidence consists of isolated regression, preserved live state, public admission checks and restore/rotation checks. A new authenticated consuming-agent action on the candidate has not been performed; it belongs to customer acceptance under fresh explicit authority.

Version 0.1.0-rc.1 identifies this integration installation package, independently of the PALO framework or ontology version.

Installation checklist#

A release administrator verifies publisher, archive checksum and file manifest. A tenant administrator configures dedicated Entra registrations and scopes. A host operator owns HTTPS, storage, backup and incident handling. The agent owner binds actual connections. An authorized reviewer makes each required decision. Use distinct people where independent review is required.

Quick start on an isolated evaluation host#

Before connecting an agent, establish customer-approved provider-enforced spending limits or shutdown controls. This package enforces no spending cap; Azure budget alerts are notifications. Use synthetic data on an isolated evaluation host.

Tested environments: Node.js 22.22.3 with Python 3.14.6 on macOS ARM64, and Node.js 22.22.3 with Python 3.12.3 on Azure Linux x86_64. The package declares Node 22.x from 22.22.3; other patch combinations and Python versions have not been qualified by these runs. Windows and other operating systems are unqualified. npm and OpenSSL are required. Native SQLite dependencies can require a compiler toolchain. Use an unprivileged dedicated account, local storage and synthetic data. Node/Python support and security updates remain the host owner's responsibility.

1. Download the archive and its SHA-256 sidecar from the same verified release page. Confirm the publisher and checksum before extraction. A matching hash checks transfer integrity; it does not certify the software or replace provenance review.
2. Extract into a new application directory outside a web root and cloud-sync folder.
3. Run node bin/palo.mjs verify. This verifies the packaged file hashes without installing or executing dependencies.
4. Review package-lock.json, then run npm ci. This downloads pinned dependencies from the npm registry and may build native SQLite support. Dependency installation scripts can execute while native SQLite support is built. Review the locked packages and their install scripts before using the isolated host. Do not run npm as root.
5. Run npm test. This uses synthetic identities, loopback listeners and temporary test data, including controlled process termination. It does not access the customer tenant or production systems.
6. Complete Microsoft Entra configuration first: copy the admission template to a private file and populate the observed customer identifiers. Only then run the initialization commands below. Continue with operations. Initialization creates an empty mandate registry and never overwrites an existing state directory.

node bin/palo.mjs init /absolute/private/palo-state /absolute/private/admission.json https://palo.example.org
node bin/palo.mjs start /absolute/private/palo-state

palo.example.org is a placeholder. The listener binds only to loopback. Starting it does not create public HTTPS or admit any caller. Never expose the internal receiver, catalog port, state directory, keys or databases.

The included target is only palo-pilot/item-001. It is a reference integration, not an adapter for an arbitrary ERP, CRM, file store or customer database. Production use requires a separately qualified target adapter and customer acceptance against the release gates.

Included and not included#

The agent and connector are configured in the customer's own Power Platform environment. The bundle includes a configuration recipe. A managed-solution export and clean import still require qualification. See the deployment order and import acceptance checks in the tenant guide.

Support and vulnerability reporting: security@paloframework.org. General evaluation enquiries: info@paloframework.org. No paid SLA, Microsoft endorsement or production support commitment is created by downloading this candidate.

Configure the customer tenant#

This procedure requires an authorized tenant administrator and an isolated evaluation environment with available Copilot capacity. It does not authorize purchases, tenant-wide consent or public exposure on the reader's behalf. Record each administrator decision in the customer's change process. Do not reuse the author's tenant, accounts, endpoints, mandates or request IDs.

1. Define ownership and resource boundaries#

Assign a host operator, identity administrator, agent owner and reviewer. Use separate directory identities and separate application registrations for agent and reviewer. For a meaningful separation-of-duties acceptance, use different people. The bundled target remains the synthetic palo-pilot/item-001; production target onboarding is a separate engineering and acceptance activity.

Choose a dedicated HTTPS origin, private local state path, maintenance owner and protected backup destination. Keep the two loopback service ports and the target port inaccessible from outside the host. Specify spend limits and who can approve changes; an application budget alert is not a provider-enforced spending cap.

2. Configure Microsoft Entra#

Create three dedicated registrations for the PALO API, delegated connector and reviewer. Record their actual application IDs and the directory object IDs of the two users. The reviewer can be an organizational guest, but the admitted identity is the object ID in the issuing tenant, not the email address or an object ID from another tenant.

For the API, request v2 access tokens and the auth_time access-token claim. Expose delegated Catalog.Update and Catalog.Review scopes with administrator-only consent. Assign the connector only Catalog.Update and the reviewer only Catalog.Review. Review any organization-wide consent separately. This integration does not require Microsoft Graph permissions.

Configure the reviewer SPA callback as the exact https://YOUR_HOST/reviewer/ address. For the Power Platform custom connector, use the exact Web callback generated by that connector and the supported federated credential it provides. Do not copy another environment's callback or federated subject, broaden audiences or manufacture a client secret to bypass a configuration problem. Verify the supported authentication option in the customer's environment.

Copy packages/palo-entra-admission/config.template.json to a private file. Fill all null tenant, application and object IDs with the observed customer values. Keep requireAuthenticationTime:true. The fixed resource and scope boundary are validated by code. A template with missing IDs fails closed.

3. Initialize and expose the host deliberately#

Run the README's initialization command as the dedicated unprivileged service user. It creates private keys, distinct catalog reader/writer credentials, an internal loopback certificate, host configuration and zero grants. Preserve the directory across upgrades. The internal certificate is valid for 30 days; monitor and rotate it under a controlled restart before expiry. Do not disable certificate verification.

Configure a publicly trusted HTTPS reverse proxy only after reviewing exposure. Preserve the configured Host, enforce body and timeout limits, and suppress authorization, body and query logging. The only public application surface is the intended HTTPS origin. Neither the directory nor internal ports is public content. Check /health separately from access control: anonymous POST requests to /mcp and /review-api must be rejected.

4. Configure the MCP custom connector and agent#

Use HTTPS POST /mcp, the x-ms-agentic-protocol: mcp-streamable-1.0 extension, and the delegated Entra authentication described above. The MCP operation must advertise both application/json and text/event-stream in its Accept request header. Use the exact tenant and API scope, never wildcard authority.

If the maker sends an Origin header, inspect the actual rejected boundary and permit only the necessary exact maker origin on the MCP route through the host's trusted allowedMcpOrigins configuration. Do not apply generic CORS or allow that origin on the reviewer API.

Initially enable only palo_catalog_read and palo_catalog_status, with Allow all disabled. Give the agent a clear purpose, icon, description, guided topics and instructions that distinguish approval, execution and verified effect. Do not claim the selected foundation model is optimal without comparison tests. A model can request a tool; deterministic server controls retain authority.

Bind the connection in both the tool editor and Test agent's Manage connections. A Connected label or completed browser sign-in does not establish a usable consuming-agent identity. Provision the initial bounded grants in Section 5 before invoking a protected read: the empty registry also denies read/status. Then start a new test session and inspect the actual tool result.

5. Provision bounded authority and accept the customer installation#

Each role requires a grant bound to the actual tenant, principal, client, scope, API and fixed target. host.json contains the grant IDs generated by initialization; those exact IDs select the two registry entries. Empty grants deny protected reads as well as mutations. There is no network grant editor or grant-provisioning CLI in this candidate.

Prepare a private grants.next.json containing the following structure. The nulls are deliberate placeholders and are not accepted by the service. Substitute only values from the approved customer configuration and recorded change authorization.

{
  "schemaVersion": 1,
  "grants": [
    {
      "id": null,
      "role": "agent",
      "status": "active",
      "tenantId": null,
      "subject": null,
      "clientId": null,
      "apiClientId": null,
      "scope": "Catalog.Update",
      "resource": {"tenantId": "palo-pilot", "itemId": "item-001"},
      "notBefore": null,
      "expiresAt": null,
      "approvalReference": null
    },
    {
      "id": null,
      "role": "reviewer",
      "status": "active",
      "tenantId": null,
      "subject": null,
      "clientId": null,
      "apiClientId": null,
      "scope": "Catalog.Review",
      "resource": {"tenantId": "palo-pilot", "itemId": "item-001"},
      "notBefore": null,
      "expiresAt": null,
      "approvalReference": null
    }
  ]
}

For first activation, stop the owning service, preserve a private backup, independently review every binding and time, save the next registry as the same OS owner with mode 0600, then rename it over grants.json on the same filesystem. Start the service and perform a real authenticated read before proposing a change. Preserve historical entries when changing a registry; do not reuse the author's IDs or overwrite another campaign's authority. Any later extension or renewal requires a new recorded authorization and a reviewed grant/host binding change.

Disabling agent tools is a UI-level closure and does not revoke server authority. A server-side closure separately changes the active entries to a non-active status through the controlled local registry procedure, or waits for their original expiry. The current role grants do not express a server-side read-only capability. Closing them also denies protected read/status calls. Never describe agent-only tool closure as server mandate revocation.

The administrator must record the authorized duration and change reference before provisioning. No scheduler or automatic renewal is included. Expired claims, replacement credentials or changed grant content cannot silently inherit old action authority.

Record each acceptance step separately:

In this pilot, independent target readback means a separate target observation, not an independent human assessor. For customer separation-of-duties acceptance, assign the request and review roles to different people and record who operated each identity; record the observer as well. A single person using two accounts establishes only a single-operator mechanism test.

Record adverse or inconclusive outcomes and stop the affected action. Use fresh IDs and the current target version. Do not reset a live target or replay the author's historical requests. A replacement grant or token cannot inherit the old claim. If an unexecuted claim or its authority expires, preserve its status and use the explicitly governed withdrawal/successor path only where available, with fresh review. Never automatically re-propose an uncertain delivery.

6. Package and publish the customer agent through ALM#

Microsoft documents custom solutions for moving agents between environments. Package custom connectors separately and import them before the agent and connection references. Bind environment-specific connections and values in the destination, then verify topics, knowledge, icon, channels, instructions, authentication and actual tool invocation. Some properties do not transfer automatically. See Microsoft's solution export/import guidance and ALM lab.

This source archive is not a managed solution and does not prove a clean-environment import. Publish an agent only after that environment's acceptance and channel-access review. A copied prompt or an exported ZIP alone is insufficient.

Operate and recover an isolated installation#

The customer operates the host, identity registrations, reverse proxy, state storage, backups and monitoring. The release provides reference software and checks, not managed operations.

Start, observe and stop#

Use a dedicated unprivileged service user. Start with node bin/palo.mjs start ABS_STATE. Preserve SIGTERM handling and allow a graceful shutdown. The exclusive host.lock prevents a second owner from starting. Never delete a lock to make a running installation start again. After a crash, independently verify that the recorded process and catalog child have stopped before a separately controlled stale-lock recovery.

Monitor health, failed admission categories, process restarts, available disk, database integrity, certificate expiry, mandate expiry, unresolved delivery state and unexpected catalog changes. Keep raw tokens, authorization codes, PKCE verifiers, request bodies and credentials out of logs. Offline JWT validation does not provide immediate Entra revocation. Local mandate revocation is checked before dispatch, but cannot retract an already dispatched effect.

Private offline backup#

Stop the service first. Store the backup on customer-approved encrypted storage with access and retention controls. The helper does not establish that a disk or remote storage is encrypted. Backups contain private signing keys and catalog credentials and must never be uploaded to the public website, repository or support chat.

python3 bin/state_archive.py backup /absolute/private/palo-state /absolute/encrypted/new-backup

The helper acquires the same exclusive host lock, rejects symlinks, non-private files and existing destinations, checks SQLite integrity and writes a file-hash inventory. It never removes an existing host lock. Its own maintenance lock is removed when it finishes. Run under the same OS owner as the state.

Isolated restore drill#

python3 bin/state_archive.py restore /absolute/encrypted/new-backup /absolute/private/new-restore

Restore goes only to a new directory. It verifies the hashes and database integrity, preserves data and records, archives the historical grants separately, and installs an empty active grant registry. It does not start the service or renew authority. Check the restored internal certificate expiry before starting; a backup may contain an expired certificate and require the replacement procedure below. With zero grants, first verify health and denied protected calls. A real authenticated functional test requires separately authorized temporary grants on that isolated instance; it is not part of the zero-authority restore drill. Test in isolation before switching any endpoint. Record restore duration, data cut-off, request counts, catalog version and unresolved deliveries. RPO and RTO remain unqualified until measured for the customer's actual storage and operating procedure.

Never restore an older snapshot over the current target and assume lost receipts permit re-execution. Restoring runtime evidence and restoring a separate business system are different operations. Uncertain external effects require independent reconciliation before reopening mutations.

Uncertain delivery and incident containment#

inflight or unresolved can coexist with a real committed target change. They block new mutations, retries and withdrawal. Read/status remain available only while the service is running and the caller retains valid identity and mandate admission; stopping the service, revoking grants or reaching expiry also closes that inspection path. executed:false can mean no runtime completion receipt, not proof of no business effect. Preserve the journals and both target and runtime evidence. Do not delete records, change IDs, shorten the audit history or mark a delivery acknowledged simply to restore availability.

This candidate has no supported CLI or API to clear an uncertain-delivery block. During evaluation, stop further mutation attempts, preserve the private archive and compare target receipts with the exact claim and runtime evidence. Leave the affected installation closed to mutations until a separately reviewed recovery implementation is available. Do not edit SQLite records to force availability. A qualified reconciliation procedure is a production gate; the current guide does not promise a return-to-service operation for this state.

Upgrade and rollback#

Install a new verified release into a distinct application directory. Preserve the complete private state separately and take an offline backup before a compatible upgrade. Validate the new bundle and run its isolated tests before switching. Do not roll database state backward or downgrade to code that ignores withdrawals, journals or newer authority controls. Rollback must preserve all current effects and evidence and leave grants closed until reviewed.

Evaluation traffic profile#

Use one operator-driven action at a time, with explicit status inspection before a further step. This is a usage constraint, not a tested requests-per-second capacity or an implemented rate limiter. Do not run unattended retries or a load campaign against the live demonstration. A failed direct-target burst remains preserved in the development evidence; changing the listener backlog alone would not prove its cause or resolve overload behaviour.

Internal certificate replacement#

The generated internal certificate lasts 30 days. Record its expiry at initialization with openssl x509 -in /absolute/private/palo-state/internal-cert.pem -noout -enddate. Use openssl x509 -in /absolute/private/palo-state/internal-cert.pem -checkend 432000 -noout to detect expiry within five days and schedule maintenance before expiration. Initialization is not a rotation command. Rotation replaces only the internal key/certificate pair while the owning process is stopped; it does not change the gateway signing key, catalog credentials, journal or mandates.

1. Confirm no unresolved operation, stop the owning service and take the private offline backup.
2. Create a new owner-only temporary directory outside the state directory. Generate a replacement loopback pair there:

umask 077
openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout /absolute/private/rotation-next/internal-key.pem \
  -out /absolute/private/rotation-next/internal-cert.pem \
  -days 30 -subj '/CN=PALO internal loopback' \
  -addext 'subjectAltName=IP:127.0.0.1'
openssl x509 -in /absolute/private/rotation-next/internal-cert.pem -checkend 86400 -noout

1. Verify the IP subject alternative name and that the key matches the certificate. Preserve the old pair in the private backup. As the service owner, copy both replacement files into the stopped state directory and set both modes to 0600. Never rotate only one member of the pair while the service is running.
2. Start the service. Its startup checks certificate validity and loopback IP; TLS server setup checks the pair. Check health and rejection of anonymous protected calls, then perform the authorized authenticated acceptance for that environment.
3. If startup or TLS acceptance fails, stop the process and restore only the previously valid key/certificate pair from the private backup. Preserve the current databases and journals. A previously expired pair is not a valid rollback.

The rotation drill was maintainer-directed on Azure Linux on 27 October 2026 UTC, using the archive hash below and the actual isolated pilot backup. It exercised startup and anonymous admission rejection, not a fresh authenticated Copilot action. The release has no certificate scheduler. The procedure was rehearsed on the isolated pilot restore: the replacement pair was accepted, the restored host started on temporary loopback ports with zero grants, both anonymous protected calls were rejected, and the host then stopped with catalog 120/version 2 and one write preserved. The first check used a client that did not preserve the required Host boundary and received 403; the corrected check used explicit HTTP Host without changing server checks. Customer live maintenance still requires its own acceptance. Replacing the internal certificate does not replace the public reverse proxy certificate or its renewal policy.

Support boundary#

An operator owns access, incident handling and acceptance. No paid uptime promise, automatic patching, managed key custody or third-party audit is included. Refer to the production gates below and docs/RELEASE-GATES.md in the archive before using real business data or consequential tools.

Retire an evaluation#

Stop the service and close its local authority under the approved change process. Inventory the dedicated reverse proxy, endpoint, Entra registrations, connector and agent connections. Preserve private evidence and state for the agreed retention period. The authorized owners then remove only resources created for this evaluation and verify access closure. Any irreversible deletion and its timing are separate owner decisions. The package performs no automatic decommissioning or cloud deletion.

Production release gates#

The objective is a customer-tenant production product. This package remains a release candidate because the following evidence is not yet complete. Do not change productionReady or remove these boundaries merely to meet a publicity deadline.

A general-purpose or multi-tenant SaaS is outside this release. Customer ownership of a host does not itself satisfy these gates. Microsoft's Power Platform Well-Architected guidance provides useful reliability, security, operational, performance and experience review categories; citing it is not Microsoft certification.

For public communication, distinguish the completed synthetic use case, the installable candidate and the remaining production gates. Never describe this release as an approved Marketplace connector, an independently certified control, proven ROI or production-ready middleware.

Release acceptance record#

Retain the archive hash, exact Node/Python versions, test logs, dependency audit, identity and origin decisions, target effect contract, expiry times, user decision and independent target observation. Keep private operator evidence outside the public website. Record failed or inconclusive steps explicitly.

The SBOM and test inventory are separate supplements, not new files inside the immutable source archive. Each has a published checksum: SBOM checksum, test inventory checksum. The release index binds their hashes to this source archive. These checksums do not provide a publisher signature.

The archive SHA-256 is 7d58f68226d85eb8db62dbea0aa1e1d718121bf993a22f4191abeb2c06c07f8d. The file manifest verifies 146 packaged files; the manifest itself is covered by the archive hash. This is transfer integrity, not a cryptographic publisher signature.

The release does not provision cloud resources or grant authority. Any customer deployment can incur its own platform costs; its owner must establish provider-enforced limits or shutdown controls separately. An Azure budget alert does not enforce a spending cap.