# PALO Framework > PALO means Principled AI Lifecycle Orchestration. Created and maintained by Fabrizio Degni, it connects AI governance decisions with risk and impact assessment, controls, indicators and reviewable evidence. PALO supports governance and educational assessment; it does not certify compliance. PALO-AI is a developer preview, with production limits documented in its capability and readiness pages. Worked examples use synthetic data unless explicitly stated otherwise. This is a curated index of public resources. Canonical pages remain authoritative. This file grants no permissions and does not change crawler access. The following text is generated from the main content of the selected public HTML pages; navigation and forms are omitted. It is not the entire site archive. --- ## PALO Framework Canonical URL: https://paloframework.org/ Editorial date: 2026-09-25 Open-source AI governance | PALO Framework # AI governance, from principles to evidence. 17 September update: ANS, agent swarms and the evidence boundary Assess AI risks, document fundamental-rights impacts and connect controls to evidence. Start with one use case and build a reviewable dossier using PALO's local-first governance tools. Run the 10-minute evidence case Find my route No account. No mandatory telemetry. Voluntary export only. One framework. Three connected governance routes. ## Choose the governance problem, not the product name. PALO covers the complete AI lifecycle. PALO-AM and PALO-AI deepen the agentic route when delegated authority or runtime enforcement becomes the problem to solve. PALO provides the governance system. PALO-AM defines agentic authority. PALO-AI makes selected controls executable and verifiable. - Umbrella systemPALO Framework - Specialist methodologyPALO-AM - Technical enforcementPALO-AI 01 / PALO Framework ### Govern the AI lifecycle Executive, Governance, Risk, Product owner, Auditor Frame the use case, classify risk, assess impacts, select controls, define measurements and connect evidence to review. OutcomeProportionate route, Case File or evidence bundle, reviewable decision trail Ask PALO for a routeDetailed onboardingExplore guided tools 02 / PALO-AM ### Govern agentic systems Governance, Product, Risk, Assurance, Engineering Define agent identity, delegated authority, autonomy level, oversight, reversibility and the assurance evidence required. PALO-AM is the agentic governance modality inside PALO. Explore PALO-AMRun the simulator 03 / PALO-AI ### Enforce agent actions Developer, Platform engineer, Security, No-code builder Apply policy gates, exact claims, approval, one-time capability, protected execution, trusted receipt and outcome verification. PALO-AI is the technical control-plane component of PALO and remains a Developer Preview. Explore PALO-AIOpen Governance HubChoose a quickstart PALO technical extension. Current v2.7 data-assurance developer preview. ## PALO-AI: from authorized action to verified outcome New: ANS identity integration and verified offline demo Inside the broader PALO Framework, PALO-AI binds agent authority and oversight to current purpose-fit data, a signed disclosure contract, a one-time execution capability and evidence of the information flow and effect actually produced. ProposeAuthorizeApproveExecuteReceiptVerifyIncident / review Governance Hub: eight-step builder - Define purpose - Register the agent - Bound authority - Choose oversight - Define outcome - Connect integration - Test boundary - Publish profile Developer Preview: realistic illustrative/local data; not an authenticated production console or authorization boundary. Why PALO-AI?Open the guided builderChoose a quickstart Guided journeys already available ## Start from an outcome. Leave with an artifact. These are working guided flows, not a flat catalogue. The cognitive start recommends which one matters now. Orient ### PALO Guide Find a transparent route for your role, objective, system and impact. Artifact: Accountable steps and integration classAsk PALO Govern agent actions ### Governance Hub builder Bind purpose, identity, authority, oversight and verified effects in eight steps. Artifact: Governance profile and enforcement summaryOpen the builder Connect evidence ### Assessment Path Route classification, impact, controls and evidence. Artifact: Versioned evidence bundleOpen Assessment Path Bound delegation ### PALO-AM Simulator Test action space, autonomy and reversibility. Artifact: Agentic authority tierOpen PALO-AM Frame ### AI Model Canvas Make purpose, ownership and assumptions explicit. Artifact: AI use-case canvasBuild the canvas Classify ### Risk Tiering Establish an initial EU AI Act risk route. Artifact: Classification rationaleCalculate the tier Assess ### FRIA Assessment Structure fundamental-rights impact questions. Artifact: FRIA assessment recordStart the FRIA Measure ### KPI/KRI Generator Turn governance intent into observable indicators. Artifact: KPI/KRI registerGenerate indicators Control coding agents ### Vibe Coding gate Preview a governance check before every coding-agent tool call. Artifact: Pre-tool decision evidenceOpen the gate preview Understand, apply, review ## Put AI governance into practice ### Build a reviewable evidence record Follow a fictional invoice agent through its authority boundary, expected effects and human review conditions. Read the worked governance case ### Choose indicators that support decisions Define a useful KPI or KRI with a denominator, evidence source, accountable owner and review action. Explore KPI and KRI examples ### Trace the research behind PALO Read the publications, doctoral-thesis context and source record maintained by Fabrizio Degni. Research and preferred citation Explore framework background and specialist modules History, principles, complementary lifecycle context and the full module catalogue The PALO value proposition ## From theory to practice PALO operationalizes responsible AI governance by turning principles into decisions, controls, measurements, and evidence that a team can use. Find your operating path 01 Frame02 Classify03 Assess04 Control05 Measure06 Prove and review 01 ### Frame the use case Make the purpose, stakeholders, affected people, lifecycle owner, and intended outcome explicit before implementation begins. AI Model Canvas Human Agency Risk Map Tech Trends Observatory AI Incident Observatory 02 ### Classify the case Translate the context into an initial risk route, check relevant obligations, and record why the classification is justified. Risk Tiering Calculator Framework Comparison Regulatory Watch 2026 03 ### Assess impacts and delegated action Identify fundamental-rights impacts and, where systems can act or use tools, define authority, autonomy, action space, and human oversight. FRIA Assessment PALO-AM Assessment Path 04 ### Design and operate controls Connect the risk to engineering, process, and review controls. Use specialist modules when the risk concerns AI-assisted development, hidden behavior, or data integrity. Vibe Coding Governance AuditBench Explorer Poisoning Boomerang 05 ### Measure, evidence, and review Turn the governance intent into KPI/KRI, collect the route and sources, export the evidence bundle, and keep the work usable in the next review. KPI and KRI Generator Evidence Bundle Documentation Library P.A.L.O. Toolbox European policy contribution / September 2026 ## Governing delegated AI action in Europe Explore PALO's complementary proposal for the AI Act and enacted Digital Omnibus: accountable mandates, bounded agent actions, verified effects and a proportionate institutional pathway. Read the EU proposal and use the review toolkit Independent discussion proposal. PALO-AI remains a developer preview; no EU endorsement is implied. PALO v3.1.0 ## Start here Three clear entries for the first governance conversation. Choose a starting point, then keep the decision connected to evidence. 01 Classify ### Classify the case Translate purpose, actor, context, and affected people into an initial risk route. Open Risk Tiering 02 Assess ### Assess impacts Use the guided path to check Article 27 context and fundamental-rights questions. Start Assessment Path 03 Evidence ### Build the evidence Route the work to controls and KPI/KRI, then export a versioned local evidence bundle. Build the bundle Regulatory Watch 2026 ## Dates with sources Article 4 literacy, Article 50 transparency, GPAI enforcement and the high-risk timeline, with official sources reviewed on 22 September 2026. Open Regulatory Watch PALO Assessment Path ## From case to record Risk Tiering, contextual FRIA, controls, KPI/KRI, and a local JSON or Markdown bundle with version, sources, and disclaimer. Open the guided path Documentation Library ## Readable online Browse the lifecycle, interactive modules, primary PDFs, worksheets, source links, and contribution notes in one indexable hub. Open Documentation Library Platform Map ## Navigate by decision See implemented, foundation, and research states; follow stakeholder intent to a module and the artifact it should produce. Open Platform Map Release verification ## PALO 3.1 and PALO-AI 2.7 baseline Review the source revision, CI run, validation totals, negative-test coverage, tagged artifact checksum and current maturity limits. Open release record Proof and Community ## See the public record Review public references, the Human Economic Forum context, app store links, source notes, and the media kit. PolicyWatcher adds an external policy-monitoring companion. Open RecognitionCommunityPolicyWatcher ## The Problem: "ROI Myopia" Traditional frameworks focus narrowly on immediate financial returns, ignoring the "hidden iceberg" of risks: algorithmic bias, reputational damage, and regulatory penalties. - Ignoring long-term ethical debt - Lack of standardized governance - Reactive instead of proactive compliance ## Why PALO? Principled. Actionable. Live. PALO isn't just a checklist. It's a comprehensive Lifecycle Orchestration paradigm. We convert abstract ethical principles into concrete KPIs, decision gates, and operational realities. 360 deg Evaluation Ethical, technical, business, and legal. 5 System activities Ideation through responsible retirement. See It In Action ## The Framework Explained The YouTube player loads when you select Play. Read the framework guide. Discover how PALO integrates ancient wisdom with modern AI governance. Play the PALO trailer 1 ### Ideation & Screening Before coding, we screen for ethical red flags. Is the project aligned with human values? 2 ### Ethical KPIs We translate "fairness" into measurable metrics like Demographic Parity Difference. 3 ### Responsible Deployment Continuous monitoring ensures the AI remains aligned with its original ethical intent. Core Tenets ## Built on Universal Values PALO synthesizes global standards into actionable business logic. ### Fairness & Non-Discrimination Proactive bias detection and mitigation strategies embedded from the very first data collection phase. ### Human Agency & Oversight Ensuring AI empowers humans. Implementing "Human-in-the-loop" protocols for critical decisions. ### Societal & Environmental Well-being Moving beyond "do no harm" to actively measuring carbon footprints and societal impact. Complementary system-lifecycle view ## Five system lifecycle activities This implementation roadmap from ideation to retirement complements, and does not replace, the canonical six-phase PALO governance loop: Frame, Classify, Assess, Control, Measure, Prove & Review. - Frame the purpose ### Ideation & Screening Ethical red flags check & strategic alignment. - Set the route ### Assessment & Planning ISO 42005 Impact Assessment & Risk Tiering. - Build the controls ### Dev & Validation Ethical-by-design & bias mitigation. - Monitor the system ### Deployment Continuous monitoring & feedback loops. - Close responsibly ### Decommissioning Responsible end-of-life & data disposal. Not sure where governance should enter this system lifecycle? Find your PALO route New Tool Available ## PALO Model Canvas AI A comprehensive evaluation framework for responsible AI use cases. Assess risks, ensure compliance, and make informed decisions aligned with global standards. ### Strategic Alignment Evaluate AI projects against organizational objectives and societal well-being. ### Risk Assessment Dynamic benchmarking based on EU AI Act risk tiers and PALO framework metrics. ### Integrated KPIs Track technical, business, and ethical KPIs with real-time compliance scoring. ### Standards Mapping Aligned with ISO 42001, ISO 42005, OECD AI Principles, and NIST AI RMF. Launch Model Canvas Free to use - No registration required - Export your analysis EU AI Act Readiness ## Fundamental Rights Impact Assessment A governance-support assessment for identifying fundamental-rights impacts before deployment. It supports Article 27 readiness for deployers within its scope. ### What is FRIA? A Fundamental Rights Impact Assessment (FRIA) is a systematic evaluation that supports Article 27 readiness for certain deployers of high-risk AI systems. It identifies, analyzes, and documents how an AI system may affect the fundamental rights enshrined in the EU Charter, including dignity, privacy, non-discrimination, and fair trial. ### When is a FRIA required? - Legal Scope: Article 27 applies to specific in-scope deployers, not every high-risk deployment - Public Services: Relevant for public authorities and private entities providing public services - Accountability: Documents due diligence and risk mitigation efforts ### 51 EU Charter Rights Complete coverage of all fundamental rights from the EU Charter of Fundamental Rights. ### Scenario-Based Analysis Identify up to 5 impact scenarios with affected groups and root cause analysis. ### Risk Prioritization Automatic severity x likelihood calculation with visual risk matrix. ### Import & Export Save your assessment, resume later, or download a comprehensive report. Start FRIA Assessment Free online tool - Client-side processing - Your data stays local Mobile toolbox Available ## P.A.L.O. Framework Toolbox Carry a private, offline pre-screening workspace for responsible AI decisions across Android, iPhone, and iPad. Open Toolbox details Google Play App Store Offline by design. Preliminary self-assessment only; no compliance certification or legal advice. - Risk and impact screeningRisk Tiering and FRIA preparation. - Audit-ready checklistsLocal progress across major governance references. - Evidence and reportsEvidence Vault, PDF dossiers, and Markdown export. - Specialist toolsAuditBench, KPI Generator, and Model Canvas access. Alignment research Interactive ## AuditBench Explorer Investigate hidden model behaviors, practice alignment auditing, and turn findings into PALO-aligned mitigation evidence. Open AuditBench Explorer Based on the AuditBench alignment auditing benchmark by Sheshadri et al. (2026). - 14 hidden behaviorsInspect concealment, sycophancy, and policy bias. - Investigator simulatorPractice prefilling, persona sampling, and probes. - Readiness assessmentUse a 14-point checklist and radar view. - Exportable findingsRecord mitigations for each behavior category. Forensic systems analysis Case 001 ## PALO AI Incident Observatory Compare the reported July 2026 OpenAI / Hugging Face agentic incident with the authority gates of a production-hardened PALO deployment. Open Case 001 Read September updates Report facts and conditional PALO counterfactuals remain explicitly separated and source-auditable. - Source-bounded recordEvery incident claim carries a report page reference. - Two-layer incident railObserved behavior paired with exact authority gates. - Independent cut pointsAdmission, capability, receipt, verification, and hold. - Technical infographic labLandscape and vertical SVG/PNG compositions. Governance study March 2026 ## The Poisoning Boomerang Examine when crawler defenses become model-governance risks, with practical detection routes and lifecycle controls. Open Poisoning Study Research and governance analysis by Fabrizio Degni, covering EU AI Act Articles 10 and 15. - 6 poisoning toolsCompare tarpits, perturbations, and labyrinths. - 5 detection strategiesMove from policy analysis to spectral checks. - Regulatory analysisUnderstand data integrity and resilience tensions. - Lifecycle controlsMap poisoning risks across the five system lifecycle activities. ## Get in Touch Interested in adopting the PALO Framework? Connect with us directly. ### Email Us For general inquiries and implementation support. info@paloframework.org ### Connect on LinkedIn Follow Fabrizio Degni for updates and insights. View Profile ## Changelog Recent updates and new features. Platform releases and independently versioned components remain distinct. Full changelog Version inventory Release verification Release RSS RELEASE August 2026 - PALO-AI v2.7 - Data Assurance Control Plane: Added Action Claim 1.4, payload-minimized context evidence, purpose-bound Data Fitness, signed Disclosure Contracts and Receipts, tenant-bound MCP operations, continuous invalidation and fail-closed disclosure incidents. It remains a non-production developer preview. - v3.1.0 - Governance Control Plane: Added twelve applicability-aware control packs, 31 controls, 38 indicators, ten evidence-contract families and a fail-closed PALO-AI production-admission boundary. - v3.0.1 - Evidence Pack Activation: Made Evidence Pack the primary route with a preloaded local case, three gold cases, a voluntary SHA-256 validation receipt, Community Casebook tooling and a 30-day new-module freeze. - v3.0.0 - Semantic Foundation: Added stable semantic identity, lifecycle and append-only gate decisions, atomic evidence contracts, RDF/SHACL invariants, versioned mappings, a generated Semantic Inspector and digest-bound release inventory. - v2.5.0 - Full-Cycle Agentic Assurance: Added Effect Contracts, one-time capabilities, trusted Execution Receipts, authoritative Outcome Attestations, Assurance Incidents and the n8n Governed Action preview. An allowed action is no longer presented as a verified result. - v2.4.1 - PALO-AI Developer Preview: Published versioned governance contracts, a non-production MCP reference server, draft Rego v1 policies, prototype approval and evidence flows, and non-production n8n/Dify examples. Runtime enforcement, production cryptographic evidence, authenticated mobile approval workflows, production connectors and collaborative-agent-team execution remain under development. - v2.4.0 - Reliable Operational Evidence: Added deterministic publication, interoperable local case/evidence files, import/resume handoffs, board packs, the PALO-AM Simulator MVP, and critical browser flows. - v2.3.2 - Stakeholder Onboarding: Added a three-question local onboarding route, personalized module guidance, local JSON and Markdown export, and a guided handoff into the weighted workflow and 3D operational graph. - v2.3.1 - From Theory to Practice: Added the operating loop that connects all core PALO modules to concrete decisions, controls, KPI/KRI, evidence bundles, and review. - v2.2.0 - Guided Assessment and Evidence Hub: Added three Start Here entries, the PALO Assessment Path with local JSON and Markdown evidence bundle export, Regulatory Watch 2026, the web-native Documentation Hub, a unified shell, and Proof & Community media kit links. - v2.1.0 - Regulatory Readiness and Trust Foundations: Updated Article 27 and Article 50 wording, added current Commission timeline notes, refreshed privacy/security/accessibility status, completed page metadata, and published the Recognition and Sources page. NEW MODULE June 2026 - v2.0.0 - PALO-AM Agentic Governance Modality: New PALO extension for governing AI agents and agentic systems. Features five operational object cards (Identity, Authority, Risk Matrix, Control Layer, Evidence Layer), the Action-Space vs Autonomy Matrix with four tiers, a complementary five-activity system lifecycle overlay for agentic systems, 11 KPI/KRI indicators and worked enterprise scenarios. Aligned with IMDA MGF v1.5, EU AI Act, ISO/IEC 42001/42005 and NIST AI RMF. - v2.0.1 - Documentation Sync: README, roadmap, CHANGELOG, sitemap, RSS feed, store links and homepage release notes aligned with the live framework state. NEW EXTENSION May 2026 - v1.8.0 - Enterprise Security & Governance for AI-Assisted Software Development Environments (Section 4.7.X): New PALO extension covering governance of AI-assisted software delivery - functional analysis, rapid prototyping and development. Features a three-layer model (Functional Intent, Controlled Environment, Evidence & Assurance), six decision gates, KPIs/KRIs. Includes vibe coding and AI coding assistant governance. MOBILE RELEASE April 2026 - v1.7.1 - P.A.L.O. Framework Toolbox for iOS/iPadOS: App Store release for iPhone and iPad with Evidence Vault, biometric protection, PDF report generation and direct access to PALO web modules. NEW MODULE March 2026 - v1.7.0 - The Poisoning Boomerang: New research module analyzing the data poisoning ecosystem - 6 tools (Miasma, Nepenthes, Nightshade, Glaze, Cloudflare AI Labyrinth, AttackAI), 5 detection strategies, EU AI Act governance analysis (Articles 10 & 15), and full PALO lifecycle integration for data integrity governance - v1.6.0 - Android Companion App: P.A.L.O. Framework Toolbox released on Google Play as an offline, privacy-first mobile pre-screening toolkit for AI governance workflows. - v1.5.0 - AuditBench Explorer: Interactive deep-dive into 14 hidden AI behaviors, auditing techniques, investigator simulations and PALO-aligned mitigation strategies. - v1.5.0 - Companion App Landing Page: Dedicated page for the offline mobile app, with Evidence Vault, assessment tools and mobile-first governance workflow messaging. - PALO Governance Notes: Data poisoning recognized as a cross-cutting risk across all five system lifecycle activities - new compliance advisories for Article 10 & 15 obligations, FRIA integration guidance, and data integrity KPI recommendations 2026 SPOTLIGHT January 2026 - Community & Open Collaboration: Dedicated page for open-source contributors, peer review, and partner organizations - Human Agency Risk Map: New observatory tracking 18 activities humans are delegating to AI, with PALO mitigation strategies and psychological impact analysis for the age of automation - 2026 Tech Trends Observatory: Comprehensive analysis of technology predictions from McKinsey, BCG, Accenture, PwC, EY, KPMG, and Gartner with PALO governance impact assessments NEW December 2025 - Risk Tiering Calculator: 3-step wizard to classify AI use cases into EU AI Act risk tiers (Minimal, Limited, High, Unacceptable) with required documentation guidance - KPI Generator: Generate personalized Technical, Business, and Ethical KPIs based on PALO Table 2 with export to CSV/Markdown - FRIA Module: Interactive Fundamental Rights Impact Assessment tool for EU AI Act Article 27 compliance with 51 EU Charter rights, scenario analysis, and risk matrix - Accessibility: Public accessibility statement and review status, with the detailed policy available in the footer - SEO & Trust: Enhanced meta tags, Open Graph, robots.txt, sitemap.xml, and security.txt for better categorization - RSS Feed: Subscribe to PALO news and updates via RSS at feed.xml UPDATE November 2025 - Model Canvas AI: Enhanced wizard mode, use case templates, import/export functionality, and dynamic risk assessment - Comparison Tool: Side-by-side assessment comparison with visual scoring - Responsive Design: Mobile-optimized layouts across all tools LAUNCH October 2025 - Initial Launch: PALO Framework website with Model Canvas AI tool for responsible AI governance - Documentation: PALO Principles, Lifecycle stages, and KPI framework Download governance datasets and worked indicator examples --- ## AI governance assessment path Canonical URL: https://paloframework.org/PALO_AssessmentPath.html Editorial date: 2026-09-23 PALO Evidence Pack | v3 starter experience # From one AI use case to reviewable evidence. In less than ten minutes, turn one AI use case into a traceable evidence dossier that another person can review. This is a routing and evidence aid, not certification or a substitute for legal, technical, or independent assurance. Allowed is not verified. Use my own case Runs in this browser. No account. No answer is sent. Export is voluntary. Local-first assessment ## Five linked governance gates The path is a routing and evidence aid. It does not certify compliance or replace a legal, technical, or fundamental-rights review. 01 ### Risk Tiering Describe the system and its intended use. 02 ### Contextual FRIA Route fundamental-rights questions when the context calls for them. 03 ### Controls Identify oversight, transparency, data, and incident controls. 04 ### KPI and KRI Turn the governance intent into measurable follow-up. 05 ### Evidence bundle Export the route, readiness, sources, and disclaimer. Built on the PALO Assessment Path. Case workspace | Step 1 to 4 ## Classify the case and build the route The form runs in your browser. No answer is sent to a server and no account is needed. No case loaded. Start below or import a PALO case/evidence JSON file. Import JSON The synthetic agentic invoice case is ready to load. ## Your PALO route ### Recommended next steps Inspect full Evidence Bundle JSON Voluntary local export ### Local validation receipt Check this evidence case against the published schema and create a SHA-256 digest. The receipt records a local validation result; it is not certification or independent assurance. No validation receipt created yet. Optional after-deployment monitoring signal Import a PolicyWatcher observation only when the core case route is ready. External monitoring companion | local receiver ### PolicyWatcher monitoring signal Import a structured observation locally. PALO preserves the complete signal and flags Measure and Prove for accountable review; confidence does not determine legal significance or control effectiveness. Optional companion. After deployment, PolicyWatcher can follow public privacy-policy and terms-of-service changes that may affect the operating context. Keep the original source and human review in the PALO evidence record. Import signal JSON Signal schema PolicyWatcher Observatory Confidence methodology Trust & Quality No signal imported. PolicyWatcher remains separate from PALO and no case data is sent to the portal. Use the route as a starting point. The export includes PALO version, route logic, evidence readiness, official source links, and a plain-language disclaimer so the next reviewer can see what was assessed and what remains open. --- ## Fundamental rights impact assessment Canonical URL: https://paloframework.org/PALO_FRIA.html Editorial date: 2026-09-25 Use PALO FRIA to organize evidence about how an AI use case may affect fundamental rights. Record the deployment context, affected people, mitigation and review decisions. See what a useful assessment record contains. ## What is FRIA and How to Use This Tool Click to expand the guide Collapse ### What is FRIA? A Fundamental Rights Impact Assessment (FRIA) is an Article 27 assessment for certain deployers of high-risk AI systems under Article 6(2). It helps identify how an AI system may affect the fundamental rights protected by the EU Charter in its specific deployment context. Who must conduct FRIA? - Public authorities deploying in-scope high-risk AI - Private entities providing public services - Deployers of in-scope creditworthiness and life or health insurance risk systems - Other organizations using this tool voluntarily as a readiness assessment ### How to Use This Tool - Step 1 - Context: Enter AI system details and classification - Step 2 - Checklist: Answer governance and compliance questions - Step 3 - Scenarios: Identify potential negative impact scenarios - Step 4 - Assessment: Rate severity and likelihood of each impact - Step 5 - Mitigation: Document risk mitigation measures - Step 6 - Decision: Make deployment decision and generate report Important: This tool processes all data locally in your browser. No information is sent to any server. Use the Export button to save your progress and Import to resume later. Regulatory status, reviewed 11 July 2026: The European Commission currently indicates that Annex III high-risk rules apply from 2 December 2027 and product-embedded high-risk rules from 2 August 2028. This tool is a governance-support and pre-screening resource, not legal advice or a compliance certification. Review the current Commission guidance. 1 Context 2 Checklist 3 Scenarios 4 Assessment 5 Mitigation 6 Decision ## AI System Context Provide information about the AI system being assessed. Tip: Use this assessment to prepare evidence before deployment. Article 27 applies to specific in-scope deployers, including public authorities, public-service providers, and certain creditworthiness and insurance use cases. AI System Name * Deployer Organization * AI System Description * AI Act Risk Classification FRIA supports Article 27 readiness. A legal obligation applies only to deployers within its scope. Intended Use Context Assessment Date Assessor Name ## Context Analysis Checklist Answer these questions about your AI system's governance, data, and oversight. ## Impact Scenarios Identify up to 5 scenarios where the AI system could negatively affect fundamental rights. ## Severity & Likelihood Assessment Assess the severity and likelihood of each identified impact. ## Mitigation Measures Document existing and planned measures to mitigate identified risks. ## Deployment Decision Review your assessment and make a deployment decision. Confidence in Assessment Deployment Decision Decision Rationale Step 1 of 6 ## Build a reviewable fundamental-rights impact record A useful fundamental-rights impact assessment connects a defined use case to affected people, plausible harms, safeguards and accountable decisions. Completing a checklist alone does not demonstrate that risks are adequately controlled. ### What to prepare - The intended purpose, deployment setting, responsible organization and people affected. - The evidence supporting each impact judgment, including uncertainty and information still missing. - Mitigation owners, human oversight, routes for raising concerns and conditions for reassessment. - A dated record of decisions and the reasons for accepting, changing or stopping the planned use. ### Example: an AI-supported service decision Map the decision path from data collection to human review and the outcome experienced by the individual. Consider who may be excluded, how errors can be challenged and whether the reviewer can meaningfully change the outcome. Keep the assessment tied to the actual deployment rather than a generic model description. Does PALO determine whether Article 27 applies? PALO supports preliminary readiness and voluntary governance work. Determine the applicable duties from the current official sources, actor role and deployment context with the responsible reviewer. The tool is not a legal opinion or certification. Review official regulatory sourcesStart with risk screeningConnect impacts, controls and evidence ## Try a completed fictional FRIA record A public-service triage example records an affected group, two rights, illustrative impact ratings, missing evidence, mitigation owners and a decision to halt deployment. It uses synthetic information and leaves legal classification unresolved. Download the worked FRIA JSON. Save your current work first, then use Import to inspect the example across all six steps. Explore governance registers. --- ## AI governance KPI and KRI generator Canonical URL: https://paloframework.org/PALO_KPIGenerator.html Editorial date: 2026-09-25 Select a model type, objective and sector to generate technical, business and ethical indicators. Export the selection, then assign owners and context-specific targets. See how to turn metrics into a governance register. Model Type Primary Objective Sector ## Your Personalized KPIs Technical KPIs 0 Business KPIs 0 Ethical KPIs 0 ## From AI metrics to accountable governance A KPI describes performance against an objective. A KRI signals exposure or a condition that needs intervention. The same measure can serve either role depending on its threshold, owner and agreed response. PALO's generator provides a starting selection, not a universal scorecard. ### Define the decision behind each indicator - Purpose: identify the outcome, risk or affected group the measure represents. - Method: record the formula, denominator, sampling period, data source and known limitations. - Ownership: name the reviewer, review frequency and response when evidence is missing or a threshold is crossed. - Evidence: preserve the relevant test or observation and link it to the governance decision. ### Example: a support assistant Track answer quality alongside unsupported claims, escalation quality and handling time. A faster response is not automatically a better outcome. Review a defined sample with an accountable owner and preserve the reasons for accepting or rejecting a result. Use subgroup analysis only where the data and purpose support a valid interpretation. Can I use the suggested target without calibration? Treat suggested targets as examples. Calibrate them against your system, evaluation data, affected people and risk appetite. Record uncertainty and avoid claiming fairness or safety from a single metric. Read worked KPI and KRI examplesConnect indicators to the evidence bundleInspect the versioned indicator registry ## Inspect a worked indicator register The synthetic CSV records supported answers (86/100), authority-boundary attempts (4/200) and escalation completion (18/20), with owners, review actions and limitations. These are teaching examples, not PALO deployment results or recommended targets. Download the worked KPI/KRI register · Inspect all 38 indicator definitions and reuse terms --- ## AI risk screening Canonical URL: https://paloframework.org/PALO_RiskTiering.html Editorial date: 2026-09-23 Use this EU AI Act screening tool to explore a preliminary route for one AI use case. Have the intended use, operating sector and level of autonomy ready. Read the method and limitations. Step 1: Sector Step 2: AI Function Step 3: Autonomy Results ## Select Your Sector Choose the industry where your AI system will be deployed. Healthcare HR / Recruitment Finance / Banking Critical Infrastructure Legal / Justice Public Sector Education Retail / E-commerce Marketing / Advertising ## Select AI Function What is the primary function of your AI system? Chatbot / Virtual Assistant Biometric Recognition Credit Scoring CV / Resume Screening Medical Diagnosis Content Generation Recommendation Engine Predictive Policing Social Scoring Fraud Detection ## Select Autonomy Level How much decision-making authority does the AI have? Human Assistant AI provides suggestions, human makes all decisions Human-in-the-Loop AI makes decisions, human reviews critical ones Autonomous Decision AI makes decisions without human intervention ## How to use the AI risk screening result This calculator helps governance, product and risk teams structure an initial screening conversation. It produces a hypothesis based on the answers supplied, together with issues that need further review. A short questionnaire cannot establish the legal classification of a deployed system. ### Prepare one defined use case - Describe the intended use and the people whose access, opportunities or rights could be affected. - Select the operating sector, AI function and degree of autonomy in the wizard. - Review the result against the actual actor role, deployment context, exceptions and current primary sources. - Carry the assumptions and open questions into the Assessment Path, then link the relevant controls and evidence. ### Example: recruitment support For an assistant that summarizes applications, distinguish administrative support from a system that filters, ranks or materially influences candidate decisions. Document what the system actually does and who can override it before relying on a risk route. This is an illustrative review question, not a classification of every recruitment tool. Does a low screening result mean the system is approved? No. Data protection, fundamental rights, security, contractual duties and sector-specific requirements may still require review. Record uncertainty and obtain accountable review before consequential deployment. Continue with the guided assessmentCheck dated regulatory sourcesAssess fundamental-rights impacts --- ## KPI and KRI worked examples Canonical URL: https://paloframework.org/docs/ai-governance-kpi-kri-examples.html Editorial date: 2026-09-25 Start and adoption | Public documentation # AI governance KPI and KRI examples: from measures to decisions Define useful AI governance indicators with worked formulas, denominators, evidence owners and review actions, without treating sample targets as assurance. By Fabrizio Degni | 2026-09-25 LevelguideAudiencegovernance | technical | builderProductPALO CoreStatusCurrent GuidanceLifecycleCurrentRead4 min Published HTML view | Source: docs/ai-governance-kpi-kri-examples.md On this page - What distinguishes a KPI from a KRI? - Three worked indicator definitions - Numerical example with a stated denominator - Choose thresholds from the decision context - Minimum fields for an indicator register - Keep measurement connected to review - Download the worked register AI governance indicators are useful when they connect a defined objective or risk to evidence, an accountable reviewer and an action. A dashboard with many metrics is not a substitute for that connection. PALO's KPI Generator suggests technical, business and ethical measures based on model type, objective and sector. The examples below explain how to turn a selection into a reviewable indicator register. They are illustrative definitions, not measured PALO deployment results or universal thresholds. ## What distinguishes a KPI from a KRI?# A key performance indicator tracks an intended outcome, such as the quality of reviewed answers. A key risk indicator signals exposure, such as consequential actions attempted outside a declared authority boundary. Whether a measure is useful depends on its scope, denominator, observation quality and the response it triggers. ## Three worked indicator definitions# | Indicator | Illustrative calculation | Evidence and owner | Review action | Supported-answer rate | Reviewed answers meeting the documented support rubric / all answers in the review sample | Versioned rubric, sampled answers and source checks; knowledge-service owner | Investigate failure categories and evaluate a revised system before expanding use | Authority-boundary attempt rate | Observed action requests outside the allowed scope / all observed action requests | Policy decisions with reason codes and a stated logging boundary; agent-service owner | Examine prompting, tool permissions, delegation and blocked-attempt patterns | Escalation completion rate | Escalations receiving a recorded accountable disposition within the agreed window / escalations due for review | Queue timestamps and decision records; operational review owner | Investigate overdue decisions, workload and whether escalation reaches a person able to act A blocked unauthorized request and a completed unauthorized action are different events. Track them separately. A low observed rate can also reflect missing logs rather than effective controls. ## Numerical example with a stated denominator# Suppose a reviewer examines 100 synthetic support answers using a documented rubric. If 86 satisfy every required support criterion, the supported-answer rate in that sample is 86%. That figure describes the selected sample only. It does not establish the population rate, fairness across groups, safety of consequential actions or performance after a model change. Record how the sample was selected, whether the cases are representative, the review procedure and unresolved disagreements. If some records cannot be evaluated, report that missingness rather than silently dropping it from the denominator. ## Choose thresholds from the decision context# Set targets and escalation conditions with the accountable owner. Consider the consequence of failure, exposure, user needs, baseline evidence and the ability to detect or reverse an unwanted effect. Do not adopt a suggested numerical threshold solely because it appears in a template. Pair efficiency measures with quality and risk measures. Lower handling time could accompany worse answers, reduced oversight or a larger review backlog. Investigate the trade-off before describing a change as an improvement. ## Minimum fields for an indicator register# - Name, purpose and relevant decision or control. - Formula, unit, numerator, denominator and exclusions. - Data source, observation boundary and known missingness. - System version, population or sample, and measurement period. - Owner, review cadence and agreed escalation action. - Supporting evidence, limitations and next review date. Use the versioned PALO KPI/KRI registry for the framework's indicator definitions. A project-specific register should preserve the relationship between a selected measure and the evidence that supports it. ## Keep measurement connected to review# After generating indicators, carry them into the Assessment Path. Review them alongside the use-case context and controls, rather than treating the export as an independent assurance conclusion. The invoice-agent worked example shows how an expected effect becomes a verification question. The board review template helps record the accountable decision and follow-up actions. ## Download the worked register# Download the synthetic CSV register with three rows: 86/100 supported answers, 4/200 authority-boundary attempts and 18/20 completed escalations. The file records denominators, missing-record counts, owners, review actions and limitations. These figures describe a teaching example, not a deployed PALO system. A zero missing-record count is an assumption of the example; it must not be copied into an operational register without checking completeness. For the complete definitions and reuse terms, open the governance data catalog. --- ## AI governance evidence example Canonical URL: https://paloframework.org/docs/ai-governance-evidence-worked-example.html Editorial date: 2026-09-25 Start and adoption | Public documentation # AI governance evidence: a worked invoice-agent example Follow a fictional invoice-agent case from authority boundaries to expected effects, review conditions and a locally exported PALO evidence bundle. By Fabrizio Degni | 2026-09-25 LevelguideAudiencegovernance | technical | builderProductPALO CoreStatusCurrent GuidanceLifecycleCurrentRead4 min Published HTML view | Source: docs/ai-governance-evidence-worked-example.md On this page - Start with the decision and authority boundary - Follow the six governance phases - Separate permission from the observed result - Read the example decision carefully - Export and hand over a useful record - Sources and related methodology - Compare the case with an impact-assessment record An AI governance evidence bundle connects a decision to its context, accountable owner, controls, observations and unresolved questions. It helps another reviewer understand what was assessed and what still needs to be established. A valid file format is only one part of that evidence. This walkthrough uses PALO's existing fictional invoice-exception case. It is an educational example with synthetic data and no payment, supplier or production connection. The reported sample outcome is not a measurement of a deployed system. ## Start with the decision and authority boundary# The question is whether an agent may collect invoice-exception evidence and draft a proposed resolution while a named person retains release authority. The sample permits reading synthetic invoice metadata and drafting an exception summary. It prohibits releasing a payment, changing supplier data or contacting the supplier. These distinctions belong in the record before the agent acts; an instruction to "handle the invoice" would leave the boundary unclear. Open the worked case in PALO Assessment Path or inspect the source Case File. ## Follow the six governance phases# | Phase | Question for the reviewer | Evidence to preserve | Frame | What use is intended, who is affected and who owns the decision? | Purpose, system boundary, owner and explicitly prohibited actions | Classify | Which risk route is plausible, and what context still needs review? | Screening assumptions, source references and unresolved classification questions | Assess | What could go wrong for people or delegated actions? | Impact questions, authority boundaries and oversight requirements | Control | What prevents or detects actions outside that boundary? | Proposed tool restrictions, reviewer identity and verification requirements | Measure | What observation would show that the intended effect occurred? | An expected draft and an independently checked, unchanged payment state | Prove and review | What can the evidence support, and what remains open? | Dated records, provenance, limitations, reviewer decision and follow-up The framework's phases organize the review. They do not make the sample's proposed controls production controls. ## Separate permission from the observed result# A policy decision allowing draft_exception says what may be attempted. It does not prove that the agent produced the right draft or avoided every prohibited effect. The sample's expected post-state is: json code { "draftCreated": true, "paymentReleased": false } A reviewer should also consider the other prohibited effects: supplier data must remain unchanged and no external supplier message should be sent. In a real implementation, the verification method, observation source and its trust boundary need separate validation. A tool's own success message is not independent evidence of all external effects. ## Read the example decision carefully# The source case records proceed-with-conditions. Its conditions are to keep payment release outside the agent's tool set, require reviewer identity and verify the post-state independently. That record is an illustrative decision, not an approval of your use case. Reviewers must establish whether those controls exist, are effective in the intended environment and cover the actual risks. Missing evidence should remain visible rather than becoming an implicit pass. ## Export and hand over a useful record# Use the Assessment Path to connect the context, screening and impact questions to controls and indicators. Export the local evidence bundle and review its version, source references, assumptions and unresolved questions before sharing it. Keep the original Case File and subsequent observations distinguishable. A schema-validation receipt proves that the file conforms to a contract; it does not establish legal compliance, security effectiveness or production authorization. The Case File and Evidence Bundle guide describes the interoperable record. Use the board review template to structure an accountable handover and the indicator examples to plan follow-up measurement. ## Sources and related methodology# The worked facts above come from the versioned PALO sample. The sample references the NIST AI Risk Management Framework as a starting point. Its inclusion is not an endorsement or a certification of PALO. For the wider operating model, read the PALO lifecycle guide, semantic foundation and agentic governance modality. ## Compare the case with an impact-assessment record# Download the fictional public-service FRIA record and inspect it in the FRIA tool. Save any current work before importing. Its context, affected groups, illustrative ratings, mitigation notes and halt decision show what an incomplete evidence base looks like. It is a separate teaching case, not an assessment of the invoice agent above. Use the worked indicator register to inspect formulas and denominators alongside review actions. These samples are educational inputs; they are not an executed runtime evidence bundle. --- ## Governance datasets and registers Canonical URL: https://paloframework.org/PALO_DataCatalog.html Editorial date: 2026-09-25 Open governance resources # AI governance datasets and registers Download the structured definitions behind PALO's indicators and security crosswalk. Each resource includes its scope, version, provenance, reuse terms and practical limits. These are curated governance definitions and mappings, not observations of deployed systems. A dataset download does not establish control effectiveness or compliance. ## PALO KPI and KRI registry A structured register of 38 AI governance indicator definitions. Entries connect a formula and unit to lifecycle phases, responsible roles, evidence and an action when a threshold is crossed. Suggested thresholds are illustrative and need calibration. Creator Fabrizio Degni, PALO Framework Version Schema 1.0.0; updated 23 August 2026 Status Educational, non-production Format JSON; 38 indicator definitions License MIT, under the PALO repository license Download registry JSONInspect JSON SchemaDownload a worked CSV register Start with the worked formulas and denominator examples, then use the KPI Generator to select indicators for a defined use case. ## PALO OWASP GenAI 2026 crosswalk An independent mapping of ten OWASP GenAI risk categories to three PALO routes, controls and evidence requirements. Direct, supporting and gap ratings describe design fit; they are not measurements of a deployment or proof of equivalence. Creator Fabrizio Degni, PALO Framework Version Analysis 1.0.2; reviewed 20 August 2026 Status Source-backed context; source editorial status marked provisional in the register Format JSON; 10 risks and 3 governance routes License CC BY-SA 4.0, as declared in the crosswalk Source OWASP GenAI Security Project; based on the OWASP Top 10 for LLM Applications 2026. Independent PALO mapping; no OWASP endorsement is implied. Download crosswalk JSONInspect JSON Schema Explore the crosswalk or read its method and attribution. The register preserves the scope and credit of the named technical contributor. ## Use and cite a specific version Save the original JSON, its version and retrieval date with your assessment. Preserve the license and attribution. Review the source record before reusing a mapping or threshold, and document changes you make. PALO means Principled AI Lifecycle Orchestration. The framework was created and is maintained by Fabrizio Degni. For research provenance, use the publication and evidence ledger. Curated resource index · Text of the selected public resources --- ## OWASP GenAI crosswalk Canonical URL: https://paloframework.org/PALO_OWASPGenAI2026.html Editorial date: 2026-09-25 Documentation reference | source-backed crosswalk | technically reviewed 20 August 2026 # OWASP GenAI / LLM Top 10 2026 x PALO PALO is a governance and assurance system; OWASP is a security risk catalog. The relationship is complementary, not equivalent. This page is a documentation reference - not a new PALO module or activation route. Overall verdictStrong governance fit. Incomplete technical resolution. Open Assessment Path Open source PDF View crosswalk JSON OWASP GenAI initiative Overall conclusion ## PALO routes the work. It does not erase the risk. The crosswalk is strongest where security requires ownership, bounded decisions, evidence and review. Mechanism-specific safeguards - retrieval authorization, model and data integrity, rate controls, output encoding and production identity - remain separate engineering obligations. 01 ### No elimination or certification claim PALO does not eliminate any OWASP risk and does not certify OWASP compliance. 02 ### Lifecycle assurance The framework supplies ownership, decision gates, control records, evidence and residual-risk review. 03 ### Delegated authority PALO-AM addresses identity, authority and blast radius when an LLM becomes an actor. 04 ### Selected action-path enforcement PALO-AI can enforce exact claims, policy, approval, capability and outcome evidence, but remains a non-production Developer Preview. Evidence boundary: a verified effect proves authoritative post-state against an Effect Contract. It does not prove factual truth or causal correctness. One framework | three connected routes ## Coverage deepens as the system gains authority. Read each route as a distinct governance layer. A "Direct" rating in one layer does not replace an OWASP-specific safeguard in another. 01 / Umbrella system ### PALO Framework 6Direct4Supporting0Gap Lifecycle governance, accountable owners, control selection, evidence, monitoring and review. See the framework route 02 / Specialist method ### PALO-AM 5Direct5Supporting0Gap Agent identity, delegated authority, autonomy, tool boundaries, meaningful human oversight and circuit breakers. Open PALO-AM 03 / Technical route ### PALO-AI Developer Preview 4Direct4Supporting2Gap Exact claims, policy, approval, one-time capability, trusted receipt and outcome verification. Production security gaps remain. Review the evidence boundary Coverage matrix ## Ten risks. Three governance lenses. Ratings describe design fit - not implementation effectiveness, compliance or certification. Direct A first-class PALO artifact or control materially addresses the risk. Supporting PALO contributes governance or containment; OWASP-specific safeguards are still required. Gap No specific current PALO-AI coverage for the main mechanism. Showing all 10 risks. Coverage ratings for the OWASP GenAI / LLM Top 10 2026 across the PALO Framework, PALO-AM and PALO-AI | OWASP risk | PALO Framework | PALO-AM | PALO-AI | LLM01 Prompt Injection | Direct | Direct | Direct | LLM02 Sensitive Information Disclosure | Direct | Supporting | Supporting | LLM03 Excessive Agency | Direct | Direct | Direct | LLM04 Supply Chain | Direct | Supporting | Supporting | LLM05 Data and Model Poisoning | Direct | Supporting | Gap | LLM06 Unbounded Consumption | Supporting | Direct | Supporting | LLM07 Misinformation | Direct | Direct | Direct | LLM08 Hidden Context Exposure | Supporting | Direct | Direct | LLM09 Vector and Embedding Weaknesses | Supporting | Supporting | Gap | LLM10 Improper Output Handling | Supporting | Supporting | Supporting Interpretation: "Direct" means a relevant route exists in PALO. It never means that the risk is prevented, resolved in every deployment or safe without the listed technical safeguards. Can PALO solve it? ## A precise answer, risk by risk. Each dossier separates PALO's governance contribution from the safeguards that must exist in the model, data, retrieval, infrastructure or application layer. LLM01 Prompt InjectionContain - do not promise prevention ### PALO contribution Treat model output as untrusted; apply least privilege, deterministic mediation, meaningful approval and adaptive testing around consequential actions. ### External safeguards required Multimodal filters, Unicode normalization, content provenance and red teaming that reflects the defenses actually disclosed and deployed. ### Minimum evidence Threat model, injection test suite, policy decision logs, approval records and failed-path evidence showing that privileged execution cannot bypass mediation. LLM02 Sensitive Information DisclosureGovern exposure; engineer isolation ### PALO contribution Set data-minimization and provenance requirements, establish accountable ownership, and connect detection to incident and residual-risk review. ### External safeguards required Retrieval-time chunk ACLs, tenant isolation, DLP, log and trace redaction, and protection of vector stores and credentials. ### Minimum evidence Data-flow map, access-control tests, redaction samples, tenant-boundary tests, incident route and approved retention decisions. LLM03 Excessive AgencyStrongest PALO fit ### PALO contribution Define the authority profile, minimum tools and permissions, user context, meaningful approval, one-time capability and evidence of both execution and outcome. ### External safeguards required Production identity, tenant-aware RBAC and execution architecture in which the governed path is unavoidable remain prerequisites. ### Minimum evidence Agent registry, authority profile, tool inventory, policy tests, immutable approval, capability record, trusted receipt and authoritative post-state verification. LLM04 Supply ChainGate suppliers and change ### PALO contribution Route supplier due diligence, ownership, acceptance criteria and material component changes through evidence-backed review gates. ### External safeguards required AIBOM or ML-BOM, pinned artifacts, signatures and transparency, vulnerability management, patching, and connector attestation. ### Minimum evidence Supplier assessment, component inventory, artifact digest, verification result, vulnerability status, connector attestation and approved change record. LLM05 Data and Model PoisoningGovern integrity; technical gap in PALO-AI ### PALO contribution Maintain lineage, change control, adversarial test expectations, accountable release decisions and rollback governance. LLM05 owns persistent corruption of source data, chunks, training inputs or the embedding model; the Data or Model Owner and MLOps Owner remain accountable. ### External safeguards required Pipeline integrity, poisoning and backdoor detection, signed artifacts, sandboxing and monitored feedback loops. ### Minimum evidence Dataset and model lineage, artifact signatures, persistent corpus-poisoning and retrieval-impact results, pipeline attestations, monitored feedback records and a tested rollback decision. LLM06 Unbounded ConsumptionBound action; add production abuse controls ### PALO contribution PALO-AM circuit breakers and a bounded action space constrain delegated behavior and supply escalation and stop conditions. ### External safeguards required PALO-AI lacks production rate limiting and abuse controls. Add token, action, time and cost caps, queue limits, loop detection, graceful degradation and infrastructure hardening. ### Minimum evidence Limit configuration, exhaustion and loop tests, cost alerts, circuit-breaker events, degradation test and capacity or resilience review. LLM07 MisinformationVerify decisions and effects - not truth by default ### PALO contribution Require source-backed decisions, claim-check-act separation, human review and authoritative post-state verification for consequential actions. ### External safeguards required Grounding and verified effect do not prove factual truth. Add domain evaluation, omission checks and evidence-freshness controls. ### Minimum evidence Claim-to-source trace, domain evaluation set, omission tests, reviewer decision, freshness threshold and effect-verification record. LLM08 Hidden Context ExposureExternalize authority from prompts ### PALO contribution PALO-AM and PALO-AI move critical authorization out of the prompt and into explicit authority, policy and protected execution contracts. ### External safeguards required Remove secrets from hidden context, externalize credentials and configuration, and test systematic extraction across supported modalities. ### Minimum evidence Prompt and context inventory, secret-scanning result, credential-flow diagram, extraction tests and proof of external policy enforcement. LLM09 Vector and Embedding WeaknessesCurrent targeted gap ### PALO contribution and ownership PALO can assign ownership, classify data, require controls, record evidence and decide residual risk, but does not implement the retrieval mechanism. LLM09 and the Vector Store Owner own attacks that depend on embedding geometry, similarity ranking, collisions, membership inference or inversion. Persistent source or chunk corruption is handed to the LLM05 Data or Model Owner. ### External safeguards required Pre-retrieval chunk authorization, trust-zone-separated indexes, embedding provenance and lifecycle controls, inversion resistance assessment, adversarial-query retrieval-evasion and similarity-collision testing, deletion reconciliation, ranking anomaly detection and immutable retrieval logs. Treat exported vectors and backups at source-data sensitivity. ### Minimum evidence Index topology; tenant and chunk-ACL tests; provenance and deletion reconciliation; quantified Vec2Text, ZSInvert, Zero2Text or threat-model-equivalent inversion results; retrieval-evasion, collision and threshold-straddling tests; vector-layer poisoning and ranking-manipulation results; tamper-evident trace; residual-risk decision. LLM10 Improper Output HandlingCurrent targeted extension ### PALO contribution PALO validates governance claims and can mediate consequential actions, but does not validate or sanitize every downstream content sink. ### External safeguards required Context-specific encoding, prepared queries, CSP, terminal-control sanitization, outbound fetch restrictions and generated-code security tests. ### Minimum evidence Sink inventory, encoding and injection tests, CSP policy, query binding evidence, egress controls and generated-code security results. Governance operating model ## Make the crosswalk a living review object. OWASP supplies risk context. PALO supplies the accountable loop that keeps applicability, controls, tests, evidence and decisions reviewable as the system changes. Classification Informative security source - not law, standard or certification. Accountable owner Product Security or AI Governance owns the crosswalk process; system-level risk owners remain accountable for treatment decisions. Review cadence Every 90 days, and immediately after an OWASP revision, architecture/tool/memory/data-scope change, material incident or failed critical test. Required per-risk record Applicability, owner, implemented control, test, evidence link, residual risk, decision and reopen trigger. Source discipline Preserve version, date, hash, attribution and source status. Treat mappings as source-backed context, never canonical equivalence. Model as component ### Apply this LLM Top 10 Use the present crosswalk for applications in which the model is a component within a bounded product or workflow. Tools | persistent memory | multi-step or autonomous action ### Pair with the OWASP Agentic Top 10 Apply the PALO-AM and PALO-AI route when delegated authority, tool execution, persistence or autonomous action expands the control surface. Seven-step operating loop ### A source becomes useful when it changes a decision. - 01RegisterPin the source and hash. - 02ScopeDecide applicability. - 03AssignName the risk owner. - 04ControlRecord treatment. - 05TestExercise the mechanism. - 06DecideAccept residual risk. - 07ReopenAct on change or failure. What was integrated ## Four artifacts. One explicit source boundary. The integration preserves the report as external security context. Nothing is silently promoted into a canonical PALO equivalence. - 01 / Source ### Version-pinned local PDF The reviewed OWASP GenAI / LLM Top 10 2026 v1.0 artifact. Open PDF - 02 / Registry ### Source registry entry Publisher, official URL, check date, freshness, authority and use boundary. - 03 / Data ### Versioned crosswalk JSON Machine-readable ratings and risk-level rationale, with the PDF hash pinned for downstream review. Open JSON - 04 / Analysis ### This web dossier A board-readable comparison of fit, safeguards, evidence and governance cadence. Review matrix No silent promotion: source terms remain attributed to OWASP; PALO mappings remain interpretive governance context and must be revalidated as either source changes. Limitations and attribution ## Use the mapping. Preserve the boundary. - PALO support does not imply OWASP endorsement. - The OWASP source is licensed under CC BY-SA 4.0. This page's source-derived category names, summaries and crosswalk are also published under CC BY-SA 4.0; consult the source for the complete risk descriptions and guidance. - The credited personal contribution does not mean that OWASP reviewed or endorsed the PALO analysis. - The report covers LLM applications. Agentic deployments require the paired Agentic list and the PALO-AM/PALO-AI route. PDF SHA-256ef87993a4e50ae9d83b41ff7a3d3e6320a82dfa8d4ec6bf98d0ce264b2e6108e Download the versioned crosswalk JSON and inspect its license and provenance. --- ## PALO-AM methodology Canonical URL: https://paloframework.org/PALO_AgenticGovernance.html Editorial date: 2026-09-25 PALO-AM v2.0 - CURRENT METHODOLOGY BASELINE - JUNE 2026 # Agentic Governance Modality From Model Governance to Delegated-Action Governance PALO-AM is the agentic governance modality inside the PALO Framework. It is distinct from the PALO-AI runtime. It defines the identity, delegated authority, autonomy, oversight, reversibility and assurance model for AI systems that select tools, write to systems, trigger workflows and act on behalf of the organization. Open PALO-AI Governance HubView Production Readiness Assessment: 17 September 2026. An unreleased swarm snapshot demonstrates central coordination of remote workers, shared budgets, membership revisions and supported cancellation. Evidence and remaining gaps. The baseline contract and tool counts below refer to the published runtime. FD Fabrizio DegniChief AI Officer 5Object Cards 4Risk Tiers 11KPIs / KRIs 5Lifecycle Gates ## European delegated-action governance proposal How PALO complements the AI Act and enacted Digital Omnibus: legal crosswalk, an open technical profile, a proposed pilot and operational review tools. Independent discussion proposal; no EU endorsement. Open the EU proposal PALO-AM ## The Governance Shift Model governance asks whether the model behaves responsibly. Delegated-action governance asks whether the authority delegated to the system has been justified, bounded, monitored and evidenced. ### Model Governance Does the model behave responsibly? Accuracy, bias, explainability, robustness, privacy, data lineage, output safety. -> ### Delegated-Action Governance Is the delegated authority justified, bounded, monitored and evidenced? Identity, permissions, tools, memory, autonomy, checkpoints. A hallucinated sentence can mislead. A hallucinated tool call can alter a customer record, leak sensitive data, trigger a transaction or damage an operational environment. P1 MVP ## PALO-AM Simulator Route a delegated-action configuration to a governance tier and a practical control, evidence, and KPI/KRI starting set. Results are educational governance support, not legal advice, certification, or a compliance determination. ### Developer-preview contract & approval viewer Demonstrates profile, decision and approval exchange in Web and mobile clients. It is not a production authorization interface. Import trusted agent profile Import policy decision Import approval packet Gateway URL Gateway bearer token Resolver identity Decision rationale No runtime contract loaded. Developer preview: the online endpoint is Internet-reachable but is not production-ready. Its bearer token is only a coarse developer control and does not authenticate an accountable reviewer or separate administrative roles. Use isolated test data and non-consequential tools. For a local evaluation, replace the URL with http://127.0.0.1:8787. 01 ## Five Operational Object Cards Each object is a governance domain that can be documented, implemented, tested and audited. Together they translate PALO-AM from a concept into a working operational model. 1 ### Agent Identity Profile Defines who or what the agent is inside the enterprise environment. Records the agent identifier, cryptographic provenance, accountable human owner, business unit, topology, credential lifecycle, data clearance and revocation procedure. Eliminates anonymous or shared AI execution contexts and provides the basis for attribution. 2 ### Agent Authority Profile Defines what the agent may do. Lists permitted tools, environments, data classes, read/write/delete privileges, financial thresholds, approval requirements, external endpoints, multi-agent coordination rules and abort conditions. The enforceable contract between the business and the agentic system. 3 ### Agentic Risk Matrix Determines the risk tier by examining action-space impact, autonomy level, reversibility, data sensitivity, third-party dependency, speed/volume and multi-agent complexity. Acts as the routing mechanism for required controls and decision gates. 4 ### Agentic Control Layer Implements structural safeguards around the agent: policy-as-code, API gateway constraints, token scopes, rate limits, schema validation, tool allow-lists, sandboxing, circuit breakers, human checkpoints and change-management rules. 5 ### Agentic Evidence Layer Captures auditable execution evidence without relying on private model chain-of-thought: planning artifacts, tool calls, structured inputs/outputs, policy decisions, human approvals, overrides, anomalies, incidents, KPI values and decommissioning proofs. 02 ## Engineering Control Layer PALO-AM treats governance as an enforceable architecture, not a policy statement. The language model is treated as an untrusted reasoning engine for purposes of authority. The model may propose an action; the orchestration layer decides whether it is allowed. #### Why Prompt-Layer Safeguards Are Insufficient A prompt instruction such as "do not access confidential data" is not equivalent to an access control. It can be misunderstood, bypassed, or contradicted. In agentic systems, the consequence is not merely an unsafe response - it may be an unauthorized action. High-impact actions require deterministic controls. #### Cryptographic Identity & Zero-Trust Every agent execution must carry a verifiable identity. Tool calls must include signed identity headers. Credentials must be short-lived, rotated and centrally managed. No agent may share credentials with another agent or a human user. Zero-trust: no implicit trust for any agent action. #### Tool Allow-Lists & Schema Validation Agents may only call tools explicitly listed in their Authority Profile. Each tool call must conform to a validated schema. Unrecognized tool calls must be blocked at the orchestration layer before execution. Block first, allow explicitly. #### Human-in-the-Loop Checkpoints (HITL) Human checkpoints must be designed structurally, not optionally. High-stakes or irreversible actions require explicit human approval via a decision packet - not a vague approval button. Approval telemetry must be measured against the Automation Bias Index (ABI). Meaningful oversight, not rubber-stamping. #### Circuit Breakers & Abort Conditions Each agent must have defined safe-state, rollback path and stop conditions. Circuit breakers must interrupt cascading failures in multi-agent topologies. Abort conditions must be tested in Phase 3 and validated against the CECR metric in Phase 4. Design for safe failure, not only for success. #### OpenTelemetry Observability All tool calls, approval events, policy decisions and anomalies must feed into a tamper-evident audit endpoint (SIEM, OpenTelemetry collector or governance dashboard). Evidence must be structured and machine-readable for KPI measurement. If it is not observed, it is not governed. 03 ## Action-Space vs Autonomy Matrix The primary PALO-AM routing instrument. Examines two dimensions: what can the agent change (action-space impact) and how independently can it decide (autonomy level). Any increase in autonomy or action-space after approval triggers Phase 2 reassessment. Scroll horizontally to inspect all matrix columns → ↔ Autonomy Level (rows) x → Action-Space Impact (columns) Low Impact (read-only, reversible) Medium Impact (internal write) High Impact (cross-system) Critical Impact (financial/safety/legal) High Autonomy Tier 2 Tier 1 Tier 1 PROHIBITED Medium Autonomy Tier 3 Tier 2 Tier 1 Tier 1 Low Autonomy Tier 3 Tier 3 Tier 2 Tier 2 Supervised Tier 4 Tier 4 Tier 3 Tier 3 Tier 1 - Maximum Controls Tier 2 - Controlled Tier 3 - Supervised Tier 4 - Monitored Prohibited / Redesign Required Prohibited tier: Open-ended judgment combined with production, financial, physical, legal or safety-critical write authority. The use case must be redesigned into deterministic workflow, reduced authority or human-operated execution. 04 ## PALO Five-Phase Lifecycle Overlay PALO-AM does not create a parallel lifecycle. It overlays agentic controls onto the existing PALO five-phase architecture. Governance is embedded across the full system lifecycle, not concentrated at a single checkpoint. 1 #### Ideation & Agentic Screening "Is an agent actually necessary?" Could a deterministic workflow, conventional automation or human-controlled assistant achieve the same value with lower risk? Gate: Proceed only if delegated action is justified and action-space is bounded. 2 #### Assessment & Planning "What authority is being delegated?" Complete Agent Identity Profile, Agent Authority Profile, AI System Impact Assessment, threat model, HITL design and KPI framework. Gate: Proceed only if all five objects are documented and residual risk is accepted by the correct governance body. 3 #### Development & Validation "Have structural controls been tested, not merely described?" Tool schema validation, sandbox tests, agentic red-team report, policy-as-code bundle and control test evidence. Gate: Proceed only if critical vulnerabilities are closed and approval gates cannot be bypassed. 4 #### Ethical Deployment & Monitoring "Can the organization observe, interrupt and evidence the agent?" Shadow-mode, phased rollout, runtime monitoring dashboard, incident playbook, override telemetry and KPI baseline. Gate: Proceed only with phased rollout, active monitoring and an accountable decision to expand authority. 5 #### Continuous Improvement & Decommissioning "Can the agent be retired without leaving hidden authority?" Tradecraft audit, credential revocation log, memory retention/deletion record and decommissioning certificate. Gate: Close only after credentials are revoked, logs are archived and manual fallback has been validated. 05 ## KPI / KRI Registry for Agentic AI PALO-AM extends the PALO KPI compendium with indicators specific to delegated action. The goal: measure whether the organization can bound, observe, interrupt, recover from and retire autonomous behavior. Scroll horizontally to inspect all registry columns → | Metric | Category | Measurement | Governance Rationale | Phase | Human Override Rate (HOR) | Oversight | Overrides / total action checkpoints | Detects rubber-stamping or unusual intervention patterns. | 4 | Review-Time Distribution (RTD) | Oversight | Median and distribution of review time by action complexity | Flags superficial validation or alert fatigue. | 4 | Automation Bias Index (ABI) | Behavioral | Composite of approval speed, rationale quality, dismissal clustering | Measures whether human oversight remains meaningful. | 4/5 | Tool Call Error Rate (TCER) | Technical | Malformed + hallucinated + unauthorized calls / total calls | Detects semantic misalignment, poor schemas or tool-use drift. | 3/4 | Agent Identity Sprawl Index (AISI) | Security | Unregistered identities / total detected identities | Detects shadow agents, rogue subprocesses or unmanaged credentials. | 4/5 | Multi-Agent Conflict Rate (MACR) | Systemic | Terminated/deadlocked workflows / total multi-agent runs | Detects goal conflict, message loops or coordination failure. | 3/4 | Mean Time to Intervention (MTTI) | Response | Time from anomaly detection to human or automated intervention | Measures whether control is operationally real. | 4 | Cascading Error Containment Rate (CECR) | Systemic | Contained cascade events / total cascade events | Shows whether circuit breakers stop downstream propagation. | 3/4 | Agent Identity Revocation Time (AIRT) | Decommission | Time from decommission trigger to confirmed credential revocation | Validates retirement and shadow-agent prevention. | 5 | Tradecraft Degradation Score (TDS) | Human Agency | Score from manual drills, fallback proficiency and skill-retention audits | Measures human resilience and dependency risk. | 4/5 | Policy Violation Rate per 1k Actions (PVR) | Governance | Violations of authority, data classification or compliance boundaries / 1,000 actions | Signals control design failure or misuse. | 4 No single metric is decisive. Interpret HOR, RTD, ABI and sampled audit results as a pattern, not in isolation. 06 ## Worked Scenarios Concrete examples of PALO-AM applied to real enterprise agent configurations. Each shows the same pattern: define identity, bound authority, score risk, design controls, capture evidence, plan decommissioning. #### Software Engineering Agent Tier 2 initially - Tier 1 if production deployment or protected branch write access is added Inspects repository issues, writes code to non-protected branches, runs tests and opens pull requests. Controls: Restrict write to non-protected branches; deny secret access; require human approval for PR creation; log diffs, tests, tool calls and failed access attempts. A productivity tool becomes a deployment actor if authority expands. The matrix must be recalculated whenever the agent obtains new write or deployment privileges. #### Procurement Vendor Shortlisting Agent Tier 2 (draft only) - Tier 1 if it can send offers or trigger contracts Analyzes supplier proposals, ranks vendors and prepares negotiation questions. Controls: Separate ranking from final decision; audit fairness signals; prohibit direct vendor communication without approval; preserve scoring rationale and conflict-of-interest checks. Agentic procurement raises fairness and accountability risks. The agent should support deliberation, not silently replace governance judgement. #### Finance Payment Recommendation Agent Tier 2 for recommendations - Prohibited for autonomous payment execution Reads invoices, detects anomalies and recommends payment release. Controls: Read-only invoice access; no direct payment execution; dual approval for thresholds; anomaly escalation; strict evidence logging and revocation tests. Payment authority must never be hidden inside model autonomy. Financial execution demands deterministic workflow and human authorization. #### Customer Support Refund Agent Tier 2 - Controlled Retrieves order status, drafts refund recommendations, sends support summaries, requests human approval. Controls: Denied: refund execution above EUR 50; modification of customer master data; access to payment card data. HITL checkpoints for any refund above EUR 50, legal threats, vulnerable-customer flags. Authority scope must be written explicitly. If the profile does not permit it, the orchestration layer must block it regardless of what the model proposes. 07 ## PALO Agentic Interface (PALO-AI) Developer-preview contracts and reference components for exploring governance of autonomous agents and agent teams. Data-Assurance Developer Preview. Not for production authorization. PALO-AI v2.7 adds Action Claim 1.4, Context Bridge evidence references, Data Fitness Decisions, signed Data Disclosure Contracts/Receipts, AI system registry and continuous invalidation to the identity-bound Effect Contract cycle. The reference runtime can demonstrate zero-row egress and mismatch incidents with operator-provisioned in-process connectors and synthetic data, but its strict production profile denies the bundled runtime. Storage-level tenant isolation, KMS/HSM, distributed exactly-once guarantees, high availability and independently assessed non-bypass connectors remain under development. Open the PALO-AI Governance Hub PALO-AI overview Choose an adoption path ### Modality A: Hierarchical Subagents, Prototype Parent-child contract: The preview models identities, authority limits, delegation depth, subagent count and parent metadata. Trusted spawning, lineage verification and evidence handback are not complete. - Identity & Authority checks: Hashes the subagent's prompt and verifies allowed tools. - Reference evidence: The prototype can redact and HMAC-sign records with developer-supplied server-side key material. - Missing production controls: Parent authority, spawning, exactly-once execution and evidence handback require further implementation. & ### Modality B: Collaborative Agent Teams, Specified Proposed P2P Task Claims: This release documents the intended gatekeeper and Shared Task List model; it does not implement a collaborative-team runtime. - Specified: Team Registry, teammate capabilities, Shared Task Claims and team-level evidence. - Not implemented: Peer assignment, task leases, conflict handling, shared sequence state and production human escalation. - Current boundary: The reference runtime evaluates individual Action Claims only. ### Developer Integration Specs Use the schemas, OPA policies, and MCP server tools to connect PALO to your agent workflows: #### JSON Governance Schema Define profiles, policy inputs, Action Claims, Effect Contracts, capabilities, receipts, outcome attestations, incidents and signed evidence with 23 versioned contracts, including the unreleased local Swarm Mandate prototype. Open Schema Action Claim Effect Contract #### Policy-as-Code (Rego) Evaluate draft Rego v1 policy over registered tools, operations, scopes, network targets, delegation and approval metadata. Organization-specific production policy ownership and attestation are not included. Open Policy #### Model Context Protocol Evaluate 50 reference tools over stdio or experimental bearer/OIDC-authenticated MCP Streamable HTTP, including five unreleased swarm tools for mandates, membership, status, revocation and cancellation. Open MCP Spec Capability Matrix 08 ## Standards Alignment PALO-AM is designed as an operational extension that translates global governance standards into PALO-compatible lifecycle phases, templates, matrices, KPIs and evidence gates. #### IMDA MGF v1.5 (2026) Assess upfront, meaningful human accountability, technical controls, end-user responsibility. Matrix + Authority Profile -> Identity Profile + HITL -> Engineering Control Layer -> Tradecraft preservation + training. #### ISO/IEC 42001:2023 AI management system, risk treatment, operational control, monitoring and improvement. Agentic risk treatment plan, authority controls, monitoring dashboard, management review. #### ISO/IEC 42005:2025 AI system impact assessment and documentation of impacts on individuals, groups and society. Agentic AI System Impact Assessment with action-space, autonomy, reversibility and tradecraft sections. #### EU AI Act (2024/1689) Risk classification, prohibited-practice screening, high-risk obligations, post-market monitoring. Phase 1 legal screening, Phase 2 documentation, Phase 4 telemetry, incident and change records. #### NIST AI RMF 1.0 Govern, Map, Measure and Manage AI risks. Govern with object cards; Map with matrix; Measure with KPI/KRI registry; Manage with controls and decommissioning. #### GDPR Purpose limitation, data minimization, access control, retention, deletion or anonymization. Data scope in Authority Profile, memory governance, retention schedule, data deletion/anonymization records. ### Developer preview available v2.7 extends the reference assurance cycle with data-governed Action Claim 1.4, Data Fitness and Disclosure bindings, OIDC tenant checks, disclosure receipts and continuous invalidation. Effect Contract, one-time capability, trusted receipts, authoritative outcome attestation and held incidents remain developer-preview components and are not a production authorization or evidence service. Available 23 versioned contracts and 50 MCP tools, including the unreleased swarm worker prototype, plus full-cycle runtime tests and an n8n governed-action preview. Harden Add durable distributed processing, connector attestation, workload identity, KMS/HSM and policy attestation. Authenticate Add principal identity, role separation and meaningful action context for accountable human approval. Implement Complete collaborative-agent teams, production connectors, mobile delivery and distributed staging assurance. --- ## PALO-AI developer preview Canonical URL: https://paloframework.org/PALO_AIGovernance.html Editorial date: 2026-09-25 v2.7 data-assurance developer preview Internet-reachable evaluation endpoints Governance before, during and after execution # Make agent authority and its real-world effect verifiable. PALO-AI is the technical control-plane component of the PALO Framework. It operationalizes selected PALO-AM controls for n8n and agentic automation platforms by binding explicit authority and policy to a one-time execution capability, a trusted receipt and verification that the action produced the declared effect. Current boundary: this release is for interoperability evaluation with isolated data and non-consequential tools. It is not a production authorization service, certification, or independently assessed security boundary. Why PALO-AI? Open the guided workspace Choose a quickstart Choose your path Read the integration guide Explore full-cycle assurance Agent / workflowAction proposal PALO-AI control path - 01Normalize claim - 02Evaluate policy - 03Approve if required - 04Execute through capability - 05Verify the effect Verified Review required Denied A policy decision is only authoritative when protected execution cannot bypass the governed path. One connected governance journey ## Method, runtime contract, role-based workspace and evidence boundary Orientation: PALO-AM v2.0 remains the June 2026 methodology baseline. PALO-AI v2.7 is the August 2026 data-assurance runtime/contracts Developer Preview. Its production-admission check denies the bundled reference runtime. The Governance Hub uses illustrative/local data and is not a production console. 17 September 2026: the experimental ANS bridge and the unreleased swarm snapshot have separate evidence. Shared budgets, dynamic membership and supported cancellation are demonstrated with one central authority. Review current status and limits. Objective: govern agent actions ## Build mode refines the route. It does not replace accountability. First choose your organizational role in the guided Start. Only then choose how you build. PALO-AI keeps the Action Claim, policy decision, approval and evidence vocabulary consistent across all three implementation modes. 01 / CODE ### Code-first developer Integrate JSON Schema, MCP, OPA/Rego, CI gates and a brokered executor into an application or agent runtime. First move Validate a canonical Action Claim and force one mock tool through the governed path. Use SDK contracts, stdio or remote MCP, Rego tests, gateway adapter. Build my code-first routeRead the guide 02 / VISUAL ### No-code / low-code builder Use the visual decision gate for comparison, then move the protected action into the PALO Governed Action node and verify its outcome. First move Run the synthetic catalog demo and compare verified, mismatched and inconclusive outcomes. Use Local alpha node or native HTTP, Switch and Wait nodes. Build my visual routeRead the guide 03 / RAPID ### Rapid prototyper Connect Copilot Studio or a similar platform to a deliberately narrow set of PALO MCP tools, without writing policy code first. First move Select one authority profile, one reversible action and one accountable reviewer. Use Streamable HTTP MCP, guided profiles and evidence review. Build my rapid routeRead the guide New guided Governance Hub ## One control plane. Two role lenses. No JSON required to start. The same governance state is translated into an executive cockpit and a technical workbench. Leaders see coverage, authority, verified outcomes and exceptions. Builders configure the exact agent, tool, resource, oversight and outcome verifier through an eight-step guided flow. - Executive lensIndependent signals, portfolio exposure, decision queue and assurance reporting. - Technical lensRegistry, policies, executions, approvals, incidents and integrations. - Progressive disclosurePlain language first; generated Action Claims, Effect Contracts and policy inputs remain inspectable. Prototype boundary: this browser interface uses realistic evaluation data. Production multi-user operation still requires an authenticated backend-for-frontend, tenant-aware roles, managed keys and independent security assurance. Launch the white workspace Read the user guide Review the product specification Selected product direction: a guided governance builder that hides implementation complexity until the user asks for it. Portable governance lifecycle ## From intention to verifiable outcome - 01ProposeAn identified agent or workflow requests an action. - 02NormalizeResource, operation, path, host, network intent and arguments become one Action Claim. - 03EvaluateSchema, registry and Rego policy fail closed on malformed or missing context. - 04ApproveWhen required, a reviewer resolves the exact immutable claim. - 05ExecuteThe protected credential or tool is reachable only through the governed path. - 06ReceiptThe trusted executor records what was actually attempted without accepting caller-supplied success claims. - 07ObserveA separately registered verifier retrieves authoritative post-state. - 08Verify effectExpected and forbidden effects resolve to verified, mismatch or inconclusive. - 09EscalateMismatch and uncertainty create a resource hold and a reviewable assurance incident. Deployment choice ## Local remains possible. Cloud becomes a governed service boundary. The contract stays portable; identity, keys, persistence, availability and network trust change by deployment mode. Swipe horizontally to compare every deployment field. | Mode | Best fit | Current availability | Trust boundary | Local sidecar | Code-first development, self-hosted n8n and offline evaluation. | Implemented preview | Keep OPA, registry, ledger and credentials on the trusted host or private container network. | Hybrid | Local/private workflows calling a remote PALO decision service over HTTPS. | Prototype | Workflow data crosses the organization boundary; minimize claims and retain protected execution locally. | Managed cloud | Multi-team governance with central policies, approvals, evidence and operations. | Target architecture | Requires tenant isolation, workload identity, RBAC, KMS/HSM, HA and independent assurance. | Private cloud / VPC | Regulated or enterprise environments needing organizational control and network isolation. | Target architecture | Customer-owned identity, network, keys, retention and operational controls integrate with the PALO service. HTTPS Gateway: developer previewhttps://governance.paloframework.org/gateway Streamable HTTP MCP: developer previewhttps://governance.paloframework.org/mcp Internet-reachable does not mean production-ready. The current VPS adds HTTPS termination and network isolation, but not production workload identity, least-privilege RBAC, managed keys, high availability, distributed exactly-once semantics, attested execution or independent security review. Compare cloud architecturesDeploy the preview VPS stack Integration is not enforcement ## Platform capability matrix A visible check helps people understand a decision. It becomes an authorization boundary only when the protected tool and credential cannot be reached around it. Swipe horizontally to compare enforcement coverage. | Platform | Visual gate | Brokered execution | Runtime interception | Authoritative today? | n8n | Package 0.2 gate or MCP Knowledge Reader | Package 0.2 Governed Action prototype | Not implemented; alternate credentials or tool paths can bypass the node | No. MCP config validated; package unpublished and unverified | Copilot Studio | Reader/Curator over Streamable HTTP | Target via narrow PALO operational tools | Platform-owned controls | No. Config validated; live tenant pending | Dify | Native MCP Knowledge provider | Gateway example or Agent Strategy target | Plugin-owned target | No. Partial config; live build pending | LangChain / LangGraph | Middleware decision feedback | Recommended adapter shape | Before-tool middleware / interrupt | No. Adapter not packaged | Node-RED | Custom node or subflow target | Broker required | Self-hosted hook target | No. Specified pattern | Make | HTTP or custom-app step | PALO-controlled API target | No universal interceptor | No. Direct actions must be removed | Zapier | Private/public integration target | PALO-controlled action target | No universal interceptor | No. Direct actions must be removed Enforcement invariant: do not expose a direct privileged tool path beside its PALO-governed broker and then describe the flow as enforced. Knowledge integrations: the dedicated canonical-only Reader is a production candidate with separate live acceptance gates. Reader/Curator configurations for 11 MCP hosts are tracked in the Knowledge Copilot matrix; protocol or configuration validation is not live host qualification, and the Curator does not inherit Reader status. Assurance before scale ## What is real, and what still blocks production The developer preview includes canonical schemas, a trusted versioned registry, Rego v1 policy evaluation, replay controls, transactional local persistence, signed evidence and official-SDK MCP transports. These are evaluation primitives, not evidence of an independently assured production service. ### Required closure - OIDC or mTLS workload identity and least-privilege tenant RBAC - KMS/HSM-backed signing, rotation and separation of duties - Distributed durability for consumed one-time capabilities, workload identity, connector isolation and removal of alternate privileged execution paths - Durable approval resume, HA state, outbox, recovery and external evidence anchoring - Threat model, independent penetration test, cryptographic review and supply-chain assessment Open Production ReadinessSecurity and scale planCapability matrixDocumentation Library Current publication boundary ## Precisely what this release claims Prototype ### n8n visual decision gate Locally installable alpha package with Allowed, Approval Required and Denied outputs. It does not execute the protected target. Prototype ### Governed executor Package 0.2 binds an Effect Contract to a one-time capability, executes through a registered connector, records a signed receipt and verifies authoritative post-state. Alternate credentials or tool paths can still bypass this preview. Specified ### Secure approval resume Target flow binding authenticated reviewer authority, exact claim digest and one-time workflow continuation. Specified ### Workflow admission Target deployment gate that rejects flows containing bypass paths before activation. Publication status: n8n-nodes-palo-ai is unpublished, unverified and not accepted by n8n. npm publication, catalog discovery, n8n verification and connector submission are deferred until real integration and security gates pass. Architecture preview ## Bring one safe workflow. Challenge the boundary. We are looking for n8n builders, platform integrators, policy authors and security reviewers willing to test a non-production workflow with mock or reversible actions. Do not share secrets, personal data or production credentials. Read the community discussion draftDesign-partner intakeMarket-entry plan --- ## n8n governance guide Canonical URL: https://paloframework.org/docs/palo-ai-n8n-governance-control-plane.html Editorial date: 2026-09-23 Architecture and integration | Public documentation # PALO-AI Governance Control Plane for n8n and Agentic Automation Platforms Explore four PALO-AI integration patterns for n8n: policy gates, governed execution, human approval and workflow admission in a developer preview. By Fabrizio Degni | 2026-09-23 LevelguideAudiencetechnical | builderProductPALO-AIStatusDeveloper PreviewLifecycleCurrentRead8 min Published HTML view | Source: docs/palo-ai-n8n-governance-control-plane.md On this page - Product boundary - Design principles - Four visual integration patterns - Pattern A - Visual Governance Decision Gate - Pattern B - PALO Governed Executor - Pattern C - Digest-Bound Human Approval and Secure Resume - Pattern D - Workflow Admission and Continuous Governance - Reference architecture - n8n adapter contract - Proposed n8n package - Deployment profiles - Developer preview - Enforced self-hosted target - Enterprise/OEM target - Out-of-the-box policy packs - Delivery sequence - Public claim discipline - n8n references Status: current architecture preview updated for the PALO-AI v2.7 data-assurance developer preview on 25 August 2026. The patterns include implemented reference prototypes and future production controls; none is represented as production-ready. PALO-AI is an emerging governance control plane for n8n and agentic automation platforms, designed to make authority, policy enforcement, human oversight and cryptographic evidence visible and enforceable. For runnable setup and current limitations, use the PALO-AI Governance Integration Guide, Full-Cycle Assurance Guide, public Capability Matrix and Production Readiness route. Interface appearance does not determine readiness. ## Product boundary# n8n orchestrates what an automation does. PALO-AI governs whether an identified agent or automation is authorized to propose and execute a specific action, under which policy, with which human oversight, and with which evidence. PALO-AI complements native n8n security, access control, guardrails and human-review features. It does not replace platform hardening, credential security, network controls, legal review or organization-owned accountability. ## Design principles# - One trusted decision point. n8n connectors submit canonical Action Claims to the PALO Gateway; they do not evaluate authoritative policy or sign evidence locally. - Decision is not execution. A visual allow/deny node is advisory unless execution is bound to a short-lived capability or performed by a governed executor. - The exact action is approved. Approval binds to the digest of one immutable claim. Resume never regenerates the claim, arguments, nonce or idempotency material. - Credentials stay with executors. Agents and PALO claims use credential references and redacted arguments, never raw secrets. - Evidence follows outcome. An allowed decision is not evidence of successful execution. The ledger records decision, approval and verified outcome as distinct events. - Fail closed by deployment profile. Missing profiles, malformed claims, unavailable policy and expired capabilities deny execution in enforced profiles. - Portable governance semantics. Platform adapters map vendor-specific workflow data to the same versioned PALO contracts. ## Four visual integration patterns# ### Pattern A - Visual Governance Decision Gate# Enforcement class: advisory prototype unless paired with Pattern B or Pattern D. text code [Proposed Action] -> [PALO Decision Gate] |-- allowed ----------> [Explicit next step] |-- approval required -> [Approval flow] `-- denied -----------> [Stop and alert] The node submits a canonical Action Claim to the trusted PALO Gateway. It exposes distinct decision branches and human-readable reasons. It is valuable for workflow transparency and prototyping, but it can be removed or bypassed by a workflow editor and must not be called an execution interceptor on its own. ### Pattern B - PALO Governed Executor# Enforcement class: implemented reference prototype in v2.7; production hardening and connector certification remain open. text code [AI Agent] -> [PALO Governed Tool] | v [Registry + schema + OPA] | [Approval when required] | v [Allowlisted executor] | v [Outcome evidence] The agent can call only a PALO-governed tool. It supplies a registered executorId and schema-valid arguments. The gateway resolves the executor in the trusted registry, evaluates the immutable claim, obtains approval when required, and performs or delegates the action through an unavoidable execution path. An arbitrary targetTool string is not sufficient. Production executors require a versioned registration, an argument schema, an authority profile, allowed hosts and scopes, credential isolation, timeout and retry semantics, and evidence mapping. ### Pattern C - Digest-Bound Human Approval and Secure Resume# Enforcement class: approval-state prototype; authenticated delivery and resume remain specified. text code [Pending Action] -> [PALO Approval API] -> [PALO Web or Mobile] ^ | | approve / deny | | `---- signed result ----' | [Revalidate immutable claim] | [Secure n8n resume] The mobile client never receives authority to execute a tool and should not call an exposed n8n resume URL directly. It resolves an approval through PALO using authenticated reviewer identity. The PALO backend verifies the reviewer, device/session, claim digest, expiry and terminal state before issuing a one-time resume signal. The same claim is evaluated again immediately before execution. This pattern should integrate with n8n's native human-review and wait semantics rather than duplicate their workflow lifecycle. ### Pattern D - Workflow Admission and Continuous Governance# Enforcement class: specified self-hosted/OEM enforcement pattern. text code [Create or update workflow] | v [PALO Workflow Assessor] | [Coverage + risk + profile] | | complete incomplete | | [versioned digest] [block activation] | [pre-execution verification] The assessor analyzes workflow JSON, agent and tool connections, Code or Execute Command nodes, credential references, external hosts, webhooks, destructive operations, MCP exposure and missing governance coverage. A backend hook can reject activation or execution when the required PALO profile, workflow digest or governed execution path is absent. This is the layer that turns a collection of optional nodes into instance-level governance. ## Reference architecture# Mermaid diagram source flowchart LR A["n8n Canvas / AI Agent"] --> B["PALO Visual Nodes"] A --> C["PALO MCP Governance Proxy"] H["Workflow create, update and activation hooks"] --> D["PALO Workflow Assessor"] D --> E["Versioned workflow profile"] B --> F["Canonical Action Claim"] C --> F E --> G["Registry and OPA policy engine"] F --> G G -->|"deny"| X["Execution blocked"] G -->|"approval required"| I["PALO Web / Mobile approval"] I --> G G -->|"allow + capability"| J["Governed executor"] J --> K["n8n, MCP tool or external API"] J --> L["Signed append-only evidence ledger"] ## n8n adapter contract# Every n8n action should add platform correlation metadata to the canonical PALO Action Claim: - instance and tenant identifier; - project and workflow identifier; - published workflow version and workflow digest; - execution identifier and execution mode; - node identifier, node type and node version; - run index and input item index; - credential reference, never credential material; - registered executor identifier; - tool, operation, resource, normalized path and host; - explicit network intent: none, read, write or bidirectional; - arguments and trusted argument-schema digest; - data classification, reversibility and external-communication indicators where applicable. ## Proposed n8n package# The target community package is n8n-nodes-palo-ai and should contain: - PALO Assess Workflow; - PALO Governance Gate; - PALO Approval; - PALO Governed Action; - PALO Governed MCP Tool; - PALO Evidence; - a dedicated encrypted n8n credential type; - node versioning, icons, lint, unit tests, installation tests and npm provenance; - three reference workflow templates. The community package remains separable from the self-hosted enforcement package, which supplies backend hooks, the MCP proxy and deployment configuration. ## Deployment profiles# ### Developer preview# - n8n; - PALO Gateway and official-SDK MCP server; - OPA; - PALO-owned SQLite volume; - localhost or isolated test network only; - no consequential tools, sensitive data or production credentials. SQLite is never shared with n8n. Mobile biometrics may protect access to the client but do not constitute a cryptographic reviewer signature. The current evidence prototype uses server-side HMAC keys. ### Enforced self-hosted target# - n8n with PALO backend hooks; - PALO Gateway and MCP proxy replicas; - OPA policy bundles with version and provenance; - PostgreSQL transactional state and evidence outbox; - organization-owned KMS/HSM keys; - OAuth/OIDC workload and reviewer identity; - TLS, rate limiting, observability, backup and recovery; - one-time capability consumption and distributed idempotency. ### Enterprise/OEM target# - embedded governance coverage panel and node badges; - SSO, RBAC and separation of administrator, agent, reviewer and auditor roles; - signed policy distribution and environment promotion; - high-availability approval and evidence services; - retention, export, external anchoring and assurance controls. ## Out-of-the-box policy packs# - Observe Only - assessment and evidence with no write authority. - Human Controlled - approval for external communications, writes, deletion and purchases. - Enterprise Baseline - host allowlists, scope restrictions, credential references and separation of duties. - Regulated Data - declared purpose, redaction, approval obligations and retention controls. - Agent Team - roles, delegation depth and subagent constraints have prototype support; durable team task leases, conflict handling and team-level evidence remain specified. - Vibe Coding - gate metadata is prototyped, but an unavoidable proxy for shell, filesystem, Git, deployment and secret access is not implemented. ## Delivery sequence# - Publish this architecture and collect interoperability feedback. - Package the current visual decision gate with credentials, explicit network intent and immutable-claim resume. - Add n8n workflow correlation metadata and distributed connector tests. - Implement workflow assessment and activation/pre-execution hooks. - Implement the governed executor registry and one-time capability consumption. - Integrate authenticated Web/mobile approval and secure resume. - Replace preview storage and identity controls for a distributed staging E2E. - Request n8n community-node verification only after package and provenance requirements are met. ## Public claim discipline# Use: PALO-AI is an emerging visual governance control plane for n8n and similar agentic automation platforms. The v2.7 developer preview adds Authority Context, Data Fitness, disclosure controls and continuous invalidation to governed execution and authoritative outcome verification, while remaining limited to isolated evaluation. Do not yet use: - 'production security boundary'; - 'biometrically signed execution evidence'; - 'exactly-once execution'; - 'certified n8n connector'; - 'the standard' or 'de facto standard'; - 'all n8n tool calls are intercepted' without the enforced deployment profile. ## n8n references# - Creating and deploying community nodes - External hooks - Human-in-the-loop for AI tool calls - Instance-level MCP server - Community-node verification guidelines - Sustainable Use License --- ## PALO MCP services Canonical URL: https://paloframework.org/packages/palo-mcp-server/README.html Editorial date: 2026-09-23 Start and adoption | Public documentation # PALO MCP services Distinguish PALO's canonical-only Knowledge Reader from its operational developer-preview MCP server, including setup and trust boundaries. By Fabrizio Degni | 2026-09-23 LevelreferenceAudiencetechnical | builderProductPALO CoreStatusCurrent GuidanceLifecycleCurrentRead9 min Published HTML view | Source: packages/palo-mcp-server/README.md On this page - Operational PALO-AI reference server - Developer Preview - Safety notice - v2.7 data assurance evolution - v2.6 identity and durability baseline - MCP 2026 and OIDC resource-server mode - Full-cycle reference demo - Vendor-neutral enforcement providers - Local validation This directory now contains two deliberately different boundaries: - reader-http.js + reader-server.js: dedicated PALO Knowledge Reader v1.0.0, stateless and canonical-only, admitted as a production candidate with deployment-specific live qualification pending; - http.js + server.js + core.js: operational PALO-AI v2.7 reference runtime, still a non-production developer preview. The Reader final image does not copy core.js, the curation-capable knowledge class, SQLite, OPA, operational schemas or target credentials. It verifies data/knowledge-reader-release.json before listening, registers exactly six read-only tools and rejects production startup without OIDC and the strict transport boundary. See PALO Knowledge Reader: production profile. ## Operational PALO-AI reference server - Developer Preview# The unreleased swarm execution extension provides five MCP tools for mandate registration, status, member admission, revocation and cancellation. An opt-in dispatcher coordinates remote workers with expiring leases and single-use starts. Cancellation needs a supporting connector and an authoritative observer. Run npm run test:swarm and npm run demo:swarm:distributed from the repository root; production admission remains denied. This package is the non-production reference implementation shipped with PALO-AI v2.7. It uses the split MCP TypeScript SDK 2.0 over stdio and Streamable HTTP, serving the stateless 2026-07-28 protocol and a 2025-era compatibility path from the same tool factory. Remote MCP supports OIDC/JWKS with issuer, audience, expiry, algorithm and scope validation, or an explicit shared-token development mode. The runtime demonstrates data-governed Action Claim 1.4, Data Fitness Decisions, signed Data Disclosure Contracts and Receipts, external context evidence, continuous invalidation, an AI System & Agent Registry, Effect Contract 1.1, one-time capabilities, trusted in-process executors, authoritative outcome verification, evidence signatures, incidents and a hash-chained SQLite ledger. Action Claim 1.1/1.2/1.3 and HMAC Evidence Envelope 1.0 remain supported for compatibility. PALO platform v3.1.0 also exposes twelve applicability-aware governance control packs through the palo_guide_agent prompt and six Knowledge Reader tools. They explain the released PALO semantic model, infer a transparent starting route, plan a least-privilege product integration and search/get provenance-bearing knowledge records without mutating case state. See the PALO Knowledge Copilot integration matrix, PALO Guide Agent and MCP Integration and v3.1 Governance Control Plane. Keep these knowledge tools separate from protected-action authorization and execution. The VPS reference deployment defines a six-tool Reader route at https://governance.paloframework.org/mcp-guide and a ten-tool Curator route at /mcp-guide-curator. Reader production mode is OIDC-only, volume-free and bound to the immutable canonical release. Compatibility aliases add a terminal /mcp for clients that infer the transport from the path. Curator has separate authentication and storage, adds immutable draft and review operations over a knowledge volume and does not modify released repository sources. Both profiles exclude the operational /mcp surface. The server returns profile-specific MCP instructions: search and retrieve before factual PALO claims, cite recordId and sourcePath, treat retrieved content as untrusted data, preserve authority classes and do not claim legal advice, certification, case approval or production authorization. Curator instructions additionally constrain writes to explicit immutable draft/review workflows. Client examples and the machine-readable 11-host matrix are in examples/agentic-interface/knowledge-copilot. Run npm run validate:knowledge-copilot for the static configuration suite, then follow PALO MCP Host Qualification for a real tenant test. No host is live-qualified by repository tests alone. ## Safety notice# Do not use this package to authorize or execute production tools, access sensitive data, or support consequential decisions. It is not an audited security boundary, universal exactly-once executor, production identity service, trusted approval service, compliance certification, or production evidence platform. The following controls are not provided in v2.7: - an authorization server, interactive OAuth login, EMA ID-JAG exchange, proof-of-possession, workload attestation, token issuance or rotation; OIDC mode is the MCP resource-server side of that architecture; - TLS termination, device/session assurance, rate limiting, tenant data isolation, or network perimeter controls; - production policy-bundle signing, distribution, attestation, rollback, or availability; - a distributed transaction spanning external tools; exactly-once claims remain limited to connectors with reliable idempotency semantics; - durable approval and verification tasks are single-instance; job leasing and crash recovery across multiple runtime replicas are not provided; - production attestation of executor and verifier binaries, workloads or supply chains; - KMS/HSM key custody, rotation, revocation, separation of duties, or external ledger anchoring; - complete action context and authenticated reviewer identity outside the OIDC-protected MCP surface; the Gateway and demo routes retain their separately documented preview authentication; - trusted Vibe Gate attestation or an unavoidable pre-tool-call execution proxy; - Mode B Team Registry, Shared Task Claims, peer coordination, leases, conflict handling, or team-level evidence; - monitoring, backup/restore, retention, incident response, penetration testing, or distributed staging validation. The v2.7 runtime retains a strict production profile and fail-closed startup admission check, but the bundled capability attestation deliberately cannot satisfy that profile. This makes the remaining boundary executable instead of aspirational: the SQLite, process-key and in-process connector runtime cannot start with PALO_RUNTIME_MODE=production. Validate a deployment profile independently of runtime compatibility: bash code npm run production:admission -- schemas/fixtures/palo-production-profile.valid.json --schema-only Evaluate it against the bundled reference runtime: bash code npm run production:admission -- schemas/fixtures/palo-production-profile.valid.json The second command is expected to deny the fixture. For runtime startup, set PALO_RUNTIME_MODE=production and PALO_PRODUCTION_PROFILE_PATH to a deployment-specific profile. The bundled server compares the profile with its fixed reference capability declaration and therefore fails closed; a future production host must inject and independently attest a different capability implementation before admission can be possible. OIDC-protected Action Claim 1.3/1.4 processing additionally requires the token tenant to match the authority, Effect Contract and optional metadata tenant values. This request check does not provide tenant-isolated storage. Use only isolated development data and unprivileged mock executors. Read the repository-level capability matrix and integration guide before running the server. ## v2.7 data assurance evolution# Action Claim 1.4 binds the exact claim to an allowed, unexpired, non-invalidated palo-data-fitness-decision and a signed palo-data-disclosure-contract. The runtime revalidates both before policy evaluation and before issuing the one-time execution capability. The trusted executor returns a payload-minimized palo-data-disclosure-observation; PALO compares actual sources, fields, rows, sensitive categories, redactions, recipient, provider, model, region, endpoint, trace mode, retention and export behavior with the contract. The resulting signed palo-data-disclosure-receipt is bound into Execution Receipt 1.1 and the authoritative outcome attestation. A mismatch opens the same high-severity resource hold used for incorrect write effects. Executor result payloads are not persisted for Action Claim 1.4: the runtime stores only their digest and the disclosure receipt. This proves the declared observation boundary; it does not independently attest an in-process connector or make the connector non-bypassable. External context is imported as immutable palo-external-evidence-ref records. They retain source/version/URI, normalized claims, authority and connector provenance plus a source-payload digest, but not the source payload. Fitness decisions bind the evaluated normalized claims and treat conflicting current assertions conservatively. Signed disclosure contracts and observations must remain inside the bound fitness and contract time windows. The included Actian mapper is a read-only normalization profile, not an authenticated Actian SaaS client. Continuous assurance signals invalidate prior allowed fitness decisions and revoke matching capabilities that have not yet been consumed. See PALO Data Assurance Control Plane for contracts, tools, compliance boundaries and the testable Actian vertical slice. ## v2.6 identity and durability baseline# Action Claim 1.3 adds a human principal, workload identity, credential digests, agent instance and contiguous delegation chain. The runtime validates issuer/audience constraints, delegation time windows, non-widening scopes, tenant binding and terminal agent identity before policy evaluation. Configure trust constraints with PALO_IDENTITY_POLICY_JSON and provision an authorityVerifier callback in the runtime host to validate the bound credential digests against authenticated or attested material obtained out of band. Claim 1.3 fails closed when that verifier is absent; declared issuer strings alone never authorize an action. Effect Contract 1.1 adds notExists, numberWithin, containsAll and typeIs, delayed verification, retry metadata and an explicit compensation proposal. Compensation is never executed implicitly: it always requires a new governed Action Claim. Approval and delayed outcome verification are persisted as palo-assurance-task records. Use the task MCP tools or /v1/tasks Gateway endpoints to inspect and process due work. The Gateway polls due work every PALO_TASK_POLL_INTERVAL_MS and prevents overlapping polls inside one process. The MCP transport now supports 2026-07-28 and legacy clients, but these domain records are not yet implemented through the standard MCP Tasks extension or MRTR elicitation, and they have no multi-replica lease. Set PALO_EVIDENCE_ED25519_JSON to an object containing keyId, verificationMethod, privateKey and publicKey to emit Evidence Envelope 2.0. The envelope uses RFC 8785 canonicalization and Ed25519; verifiers must obtain the public key through a trusted channel. Retain rotated verification keys through PALO_EVIDENCE_PUBLIC_KEYS_JSON. Internal execution capabilities, receipts and attestations continue to use the profile HMAC key in this increment. Verify an exported envelope without opening the runtime database: bash code npm run palo:evidence:verify -- evidence-envelope.json trusted-public-key.pem The runtime emits redacted lifecycle events through an optional telemetry sink and exposes an operational snapshot. Set PALO_OTEL_ENABLED=true to translate those events into bounded OpenTelemetry spans correlated by the PALO trace ID. Only allowlisted identifiers and lifecycle fields are emitted. The package installs the OpenTelemetry API, not an SDK, sampler or exporter; the host must register those components. ## MCP 2026 and OIDC resource-server mode# The TypeScript SDK defaults clients to the legacy handshake, so conformance tests explicitly cover both a pinned 2026-07-28 client and legacy 2025 clients. Modern HTTP requests are stateless and the SDK validates the protocol, method and tool-name headers against the body metadata. Shared-token mode remains available for isolated development with PALO_MCP_HTTP_TOKEN. For an externally reachable MCP resource, configure OIDC instead: bash code export PALO_AUTH_MODE='oidc' export PALO_MCP_PUBLIC_URL='https://governance.example.org/mcp' export PALO_OIDC_ISSUER='https://identity.example.org' export PALO_OIDC_AUDIENCE='https://governance.example.org/mcp' export PALO_OIDC_JWKS_URI='https://identity.example.org/.well-known/jwks.json' export PALO_OIDC_ALGORITHMS='RS256 PS256 ES256 EdDSA' export PALO_OIDC_ALLOWED_CLIENT_IDS='approved-mcp-client' export PALO_OIDC_TENANT_CLAIM='tid' export PALO_OIDC_ALLOWED_TENANTS='approved-tenant' Any non-loopback OIDC listener fails closed unless both the client and tenant allowlists contain explicit values. Configure PALO_OIDC_CLIENT_ID_CLAIM and PALO_OIDC_TENANT_CLAIM for the issuer's access-token format. Loopback evaluation may omit the lists, but that compatibility mode must not be exposed remotely. Programmatic callers must pass the same normalized bind host to the listener that was validated when the app was created. Loopback recognition covers IPv4 127/8 plus canonical and expanded IPv6 loopback forms. The resource publishes RFC 9728 protected-resource metadata and sends scope-aware WWW-Authenticate challenges. Direct scopes are palo:guide, palo:knowledge:read, palo:knowledge:write, palo:knowledge:review, palo:read, palo:execute, palo:review, palo:audit and palo:admin; palo:* is reserved for administrators. Role aliases include palo-knowledge-reader, palo-knowledge-curator, palo-agent, palo-reviewer, palo-auditor, palo-observer and palo-admin, each expanding to fixed least-privilege scope sets. tools/list is filtered per authenticated request, and approval, incident or knowledge-review attribution uses the verified OIDC subject/client rather than trusting a supplied identity label. This is compatible with access tokens issued by an EMA-capable authorization server, but PALO does not implement the Enterprise-Managed Authorization ID-JAG exchanges itself. ## Full-cycle reference demo# Start OPA, then run the Gateway with the synthetic catalog adapter: bash code 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' npm run palo:gateway In another terminal run npm run demo:hands-on -- --auto-approve. Add --wrong-effect to demonstrate an authorized action that produces a mismatched outcome and a held Assurance Incident. On Gateway startup, executing/pending outbox rows older than PALO_EXECUTION_RECOVERY_AGE_MS (30 seconds by default) are recovered fail-closed. The runtime creates a signed unknown receipt, an inconclusive attestation, and a held incident. Rows with a recorded receipt but no attestation resume outcome verification. This protects the reference single-instance lifecycle after interruption; it is not multi-replica leasing or a universal exactly-once guarantee. ## Vendor-neutral enforcement providers# OPA remains the default policy evaluator. The runtime now accepts a versioned palo-agentic-enforcement-provider implementation and records its provider, version, policy reference and optional decision/evidence references in each Policy Decision. The first optional provider maps PALO Action Claims to Microsoft Agent Governance Toolkit ACS pre_tool_call. It is a PALO-maintained interoperability proposal, not a Microsoft-maintained or endorsed integration. The upstream package is loaded only when selected and is not a mandatory PALO dependency. bash code npm install --no-save --package-lock=false agent-control-specification@0.3.1-beta.0 npm run demo:microsoft-agt See the PALO + Microsoft AGT quickstart for the environment configuration, trust boundaries and upgrade policy. ## Local validation# bash code npm ci npm run opa:install npm run validate:agentic Passing the included tests confirms the documented reference behavior only; it does not establish production readiness. --- ## Production readiness Canonical URL: https://paloframework.org/PALO_AIProductionReadiness.html Editorial date: 2026-09-23 Public delivery map | v2.7 developer preview # Nine gates between preview and production 17 September 2026: the experimental ANS bridge and the unreleased swarm snapshot have separate evidence. Shared budgets, dynamic membership and supported cancellation are demonstrated with one central authority. Review current status and limits. The v2.7 production profile keeps the boundary executable: data fitness, disclosure receipts and continuous invalidation are implemented as prototypes, while the bundled SQLite and in-process runtime remains denied for production until identity, tenancy, persistence, keys, connectors, resilience and independent assurance are externally implemented and evidenced. This remains a planning surface - not an authoritative project tracker, certification or release commitment. Why PALO-AI?Open data assuranceReview current capabilityDocumentation Library Conditional estimate Controlled single tenantabout 14-20 weeks Production candidate after the applicable gates and independent retest pass. Managed multi-tenantabout 24-36 weeks Production candidate / GA only after isolation, resilience and assurance evidence. Planning assumption: one dedicated product owner, one platform lead, two backend engineers, one frontend engineer, one DevSecOps engineer and fractional security/cryptography support. Ranges are directional, overlap by design and are not release commitments. Five overlapping waves ## Filter, inspect and export a local planning snapshot Browser-local only: checklist state is saved on this device for planning convenience. It is never submitted and is not evidence of implementation or approval. Wave Status Owner Wave 1 | Weeks 1-4Identity & BFFWave 2 | Weeks 3-8Keys & durable dataWave 3 | Weeks 7-12Connectors & policyWave 4 | Weeks 11-16Tenancy & resilienceWave 5 | Weeks 15-20Independent assurance 01 Wave 1 | Platform | In progress ### Workload identity and scoped authorization Local planning check Replace shared bearer tokens with workload identity, OIDC/OAuth and scoped principal/tenant RBAC. Acceptance criteria - Every machine and human request resolves to a verifiable principal and tenant. - Scopes are deny-by-default and enforced server-side. - Token rotation, revocation and negative authorization tests pass. 02 Wave 1 | Product / Platform | Planned ### Same-origin Governance Hub BFF Local planning check Put the Hub behind a same-origin backend-for-frontend with authenticated executive, reviewer and operator sessions. Acceptance criteria - No browser-held privileged runtime credential. - Role and tenant checks occur on every protected operation. - Session expiry, CSRF and privilege-escalation tests pass. 03 Wave 2 | Security | Planned ### KMS/HSM-backed key custody Local planning check Move secrets and signing keys to managed custody with rotation, revocation and separation of duties. Acceptance criteria - Application processes cannot export signing key material. - Rotation and emergency revocation are rehearsed. - Administrative and signing duties are separated and audited. 04 Wave 2 | Platform | Planned ### Durable, coordinated data plane Local planning check Replace SQLite and in-process recovery with PostgreSQL, a durable queue/outbox, multi-replica coordination, backup and tested restore. Acceptance criteria - Transactional outbox and idempotent consumers survive process loss. - Replica concurrency and lease recovery tests pass. - Encrypted backups meet documented RPO/RTO and restore is demonstrated. 05 Wave 3 | DevSecOps | Planned ### Isolated and attested connectors Local planning check Isolate and attest connector workloads, enforce egress policy and remove alternate privileged execution paths. Acceptance criteria - Protected credentials are available only to the governed connector. - Egress destinations and operations are allowlisted. - Bypass and compromised-connector scenarios are tested. 06 Wave 3 | Security | Planned ### Authenticated policy distribution Local planning check Verify policy and bundle provenance; authenticate distribution and use mTLS where the threat model requires it. Acceptance criteria - Only authorized publishers can promote versioned bundles. - Runtime verifies provenance and rejects stale, unsigned or invalid bundles. - Rollback and emergency policy procedures are audited. 07 Wave 4 | Security / Platform | Planned ### Tenant isolation and operational resilience Local planning check Add tenant-isolation, abuse/rate-limit, audit-retention and disaster-recovery tests. Acceptance criteria - Cross-tenant reads, writes and inference paths are denied under adversarial tests. - Rate limits and abuse controls fail safely. - Retention, deletion and disaster recovery meet approved policy. 08 Wave 4 | Product / Platform | Planned ### Fresh n8n package 0.2 validation Local planning check Validate package 0.2 on fresh supported n8n canvases and real reversible connectors before npm or template submission. Acceptance criteria - Clean installation and upgrade paths pass on declared n8n versions. - Allowed, denied, review, failure and verification branches pass with reversible tools. - Package provenance and documentation are independently reproducible. 09 Wave 5 | Independent assurance | Planned ### Independent cyber and cryptographic assurance Local planning check Commission threat modelling, application/API penetration testing, cryptographic design review and container/supply-chain assessment. Acceptance criteria - Independent reports define scope, methods, severity and reproducible findings. - Critical and high findings are remediated and retested. - Residual risk is explicitly accepted by accountable owners. No gates match these filters. --- ## Publications and evidence ledger Canonical URL: https://paloframework.org/PALO_Recognition.html Editorial date: 2026-09-23 01 / Research ## Research, with provenance intact. The research record includes Fabrizio Degni's doctoral thesis in Computer Science at EIMT, the foundational corporate-governance publication and a later, author-led research extension. The two published studies retain their own publication records below. Research publication · 2026 Il Framework PALO per la Corporate Governance dell’IA Fabrizio Degni Rivista Corporate Governance Numero Straordinario Research publication · Preferred citation ### Il Framework PALO per la Corporate Governance dell'IA: un paradigma per l'orchestrazione del ciclo di vita dell'Intelligenza Artificiale basato su principi in ambito aziendale The foundational journal publication presents PALO as a principle-based paradigm for orchestrating the AI lifecycle in a corporate-governance context. Author Fabrizio Degni Published 4 March 2026 Journal Rivista Corporate Governance Issue Numero Straordinario 2026 Publisher G. Giappichelli Editore Identifiers ISSN 2724-1068 · EISSN 2784-8647 Open the journal issue View issue index Published extension · Downstream research ### Orbital intelligence and the knightian Void: A Graduated Governance Model for Autonomous AI in Cosmic Exploration, Grounded in the P.A.L.O. Framework Political Science International, Volume 4, Issue 1, pages 1–20. Published 22 May 2026. ISSN 2995-326X. The paper develops the Graduated Cosmic Ethics model as an extension of PALO and adds seven cosmic KPIs for autonomous AI in space exploration. Provenance boundary: this extension is authored by Fabrizio Degni. It is published downstream research, not an independent citation of PALO. Open the published paper Primary research artifacts The repository PDFs preserve the PALO v1 research artifact and current framework document. They are primary sources, not additional journal publications. PALO v1 research PDF PALO Framework PDF Doctoral thesis · Computer Science ### THE P.A.L.O. FRAMEWORK Principled AI Lifecycle Orchestration: An Integrated Governance Architecture for Business AI Use Case Evaluation PALO Framework was the subject of Fabrizio Degni's doctoral thesis in Computer Science at the European Institute of Management and Technology (EIMT). Author Fabrizio Degni Field Computer Science Institution European Institute of Management and Technology (EIMT) Submitted to Research and Development Committee of the European Institute of Management and Technology (EIMT) 02 / Projects & GitHub ## Referenced in public work. These records show an explicit integration and an open interoperability proposal. They are evidence of public use or discussion—not proof of endorsement, upstream adoption or certification. Related project · Explicit PALO integration ### PolicyWatcher A separate civic-tech project by the same creator. Its public README aligns the methodology with PALO, locates PolicyWatcher in Deployment & Monitoring / Phase 4, and derives the KPI approach from PALO's ethical KPI paradigm. View GitHub repository Open live project PALO lifecycle Phase 4 Deployment & Monitoring Related project PolicyWatcher Public policy-change signals and ethical KPI alignment Public proposal workflow · select the image to open GitHub Discussion #3647. Community interoperability proposal · Evaluation open ### Microsoft Agent Governance Toolkit discussion The PALO-maintained adapter proposal connects AGT ACS pre-action policy evaluation to PALO downstream outcome assurance. The proposal is public and remains open for evaluation. Not maintained, certified, sponsored or endorsed by Microsoft. Open GitHub discussion Read local proposal 03 / Public record ## Coverage and public provenance. A dated record of programme listings, independent reporting and public references. Each source retains its own editorial responsibility. - 09 Dec 2025 Official programme / public provenance ### Human Economic Forum 2025 The official programme for the event at the Italian Chamber of Deputies lists Fabrizio Degni as creator of PALO. - 25 Mar 2026 Independent coverage ### Rivista AI Coverage of the P.A.L.O. Framework Toolbox 2.0 and its wider AI-governance context. - 17 Apr 2026 Public coverage ### Indie Hackers “Fabrizio Degni Introduces PALO Framework to Advance Responsible AI Governance.” - Public post Public reference ### World AI Council A public LinkedIn post refers to PALO and notes Reuters coverage. This ledger does not present the post as a direct Reuters source. Official PALO extensions & spin-offs ## An authored ecosystem, not independent recognition. - Author-maintained ### PALO-AM Agentic governance modality for delegated action and autonomy. Explore PALO-AM - Developer preview ### PALO-AI Technical control-plane for governance integration. Explore PALO-AI - PALO-owned product ### Framework Toolbox Mobile companion for local-first governance workflows. View the companion app - Research extension ### Graduated Cosmic Ethics Author-led extension in the published orbital-intelligence paper. Read the paper - Ecosystem companion ### PolicyWatcher Separate civic-tech project by the same creator. Open PolicyWatcher App availability: Google Play and App Store. These extensions are PALO-owned or author-maintained and are shown for relationship clarity. 04 / Cite PALO ## Use the preferred citation. Download BibTeX citation | Read citation metadata Preferred citation Degni, Fabrizio. “Il Framework PALO per la Corporate Governance dell'IA: un paradigma per l'orchestrazione del ciclo di vita dell'Intelligenza Artificiale basato su principi in ambito aziendale.” Rivista Corporate Governance, Numero Straordinario 2026, G. Giappichelli Editore, 4 Mar. 2026. ISSN 2724-1068; EISSN 2784-8647. Sources of truth - CITATION.cff - Canonical repository - PALO Framework PDF - Documentation Library - PALO 3.1 and PALO-AI 2.7 release verification record - European Commission AI Act Educational boundary. PALO supports governance and pre-screening. It does not certify compliance or provide legal advice. Review every use against applicable law, sector requirements and deployment context.