Paper deep dive
A Policy Algebra for Trust-Preserving Agentic AI Execution
Bhaskar Tripathi, Anurag Kumar, Ramendra Kumar, Bhavesh Gadhe
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 86%
Last extracted: 8/23/2026, 2:03:43 AM
Summary
This paper introduces a policy algebra for trust-preserving agentic AI execution, defining 'reliable capability' as a path property where agent actions must satisfy identity, profile, tool, data, memory, budget, artifact, approval, and audit constraints. The proposed algebra composes security profiles and runtime obligations to create a least-restrictive, trust-preserving state, preventing unauthorized access, budget exhaustion without output, and delegation laundering. Evaluation shows the runtime intervenes on 94.8% of policy violations while maintaining an 86.9% task completion rate.
Entities (25)
Relation Signals (24)
Bhaskar Tripathi → affiliatedwith → Volkswagen Digital Services
confidence 95% · Bhaskar Tripathi 1 ... 1 Volkswagen Digital Services
Bhavesh Gadhe → affiliatedwith → Scania CV AB
confidence 95% · Bhavesh Gadhe 2 2 Scania CV AB
Ramendra Kumar → affiliatedwith → Volkswagen Digital Services
confidence 95% · Ramendra Kumar 1 ... 1 Volkswagen Digital Services
Anurag Kumar → affiliatedwith → Volkswagen Digital Services
confidence 95% · Anurag Kumar 1 ... 1 Volkswagen Digital Services
Policy Algebra → defines → Reliable Capability
confidence 95% · This paper defines reliable capability as a path property... We propose a policy algebra that defines the reliability envelope
Policy Algebra → composes → Security Profiles
confidence 90% · Security profiles and runtime obligations compose through joins, intersections, budget narrowing, approval inheritance, and evidence accumulation
Policy Algebra → prevents → Unrecoverable Budget Consumption
confidence 90% · A successful result is not reliable if it was produced through... unrecoverable budget consumption
Policy Algebra → prevents → Unauthorized Data Access
confidence 90% · A successful result is not reliable if it was produced through unauthorized data access...
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Large language model-based agentic frameworks primarily optimize capability: whether an agent can reason, retrieve information, call tools, delegate work, and complete a goal. Enterprise execution requires a stronger property. A successful result is not reliable if it was produced through unauthorized data access, widened delegated authority, unapproved side effects, unrecoverable budget consumption, or incomplete evidence. This paper defines reliable capability as a path property: an agent is reliably capable only when it completes a task through action events that remain admissible under identity, profile, tool, data, memory, budget, artifact, approval, and audit constraints. We propose a policy algebra that defines the reliability envelope within which agent capability may be exercised. Security profiles and runtime obligations compose through joins, intersections, budget narrowing, approval inheritance, and evidence accumulation; the resulting composition is both trust-preserving and the least restrictive state satisfying all governing inputs. The algebra also propagates restrictions across multi-agent calls and introduces cost-aware artifact materialization, which redirects open-ended execution toward a recoverable outcome as budget exposure grows. The evaluation is interpreted as a reliability-capability trade-off rather than a capability benchmark: the policy-algebra runtime intervenes on 94.8% of policy-violating events while retaining an 86.9% task-completion rate, eliminates the observed profile-monotonicity and zero-artifact-exhaustion violations, and increases audit completeness to 98.6%. The method provides researchers and practitioners with formal correctness conditions, executable decision semantics, and trace evidence for building agents that are not only capable, but reliably capable.
Tags
Links
- Source: https://arxiv.org/abs/2608.16402v1
- Canonical: https://arxiv.org/abs/2608.16402v1
Trouble viewing inline? Open PDF directly →
Full Text
123,218 characters extracted from source content.
Expand or collapse full text
A Policy Algebra for Trust-Preserving Agentic AI Execution Bhaskar Tripathi 1 , Anurag Kumar 1 , Ramendra Kumar 1 , Bhavesh Gadhe 2 1 Volkswagen Digital Services, 2 Scania CV AB Emails: bhaskar.tripathi@gmail.com, anurag31296@gmail.com, karna.ramenk@gmail.com, bhaveshgadhe@gmail.com Abstract Large language model–based agentic frameworks primarily optimize capability: whether an agent can reason, retrieve information, call tools, delegate work, and complete a goal. Enter- prise execution requires a stronger property. A successful result is not reliable if it was produced through unauthorized data access, widened delegated authority, unapproved side effects, unre- coverable budget consumption, or incomplete evidence. This paper defines reliable capability as a path property: an agent is reliably capable only when it completes a task through ac- tion events that remain admissible under identity, profile, tool, data, memory, budget, artifact, approval, and audit constraints. We propose a policy algebra that defines the reliability enve- lope within which agent capability may be exercised. Security profiles and runtime obligations compose through joins, intersections, budget narrowing, approval inheritance, and evidence ac- cumulation; the resulting composition is both trust-preserving and the least restrictive state satisfying all governing inputs. The algebra also propagates restrictions across multi-agent calls and introduces cost-aware artifact materialization, which redirects open-ended execution toward a recoverable outcome as budget exposure grows. The evaluation is interpreted as a reliability– capability trade-off rather than a capability benchmark: the policy-algebra runtime intervenes on 94.8% of policy-violating events while retaining an 86.9% task-completion rate, eliminates the observed profile-monotonicity and zero-artifact-exhaustion violations, and increases audit completeness to 98.6%. The method provides researchers and practitioners with formal correct- ness conditions, executable decision semantics, and trace evidence for building agents that are not only capable, but reliably capable. Keywords Agentic AI · Reliable capability · Multi-agent systems · Policy algebra · Runtime governance · Trust-preserving execution · Cost-aware execution 1 arXiv:2608.16402v1 [cs.AI] 17 Aug 2026 1 Introduction Agentic AI systems change the security problem of machine learning applications. A chatbot produces text; an agent can act. It may search documents, retrieve confidential knowledge, call Representational State Transfer (REST) APIs, use a Model Context Protocol (MCP) tool, update memory, create a ticket, send an email, trigger a workflow, write to a database, or delegate part of a task to another agent. Recent language-agent work shows this shift from text generation to interactive action through web interaction, tool use, memory, planning, and environment feedback [9, 13, 12, 14, 11, 10]. These capabilities make agents attractive for enterprise automation because they connect reasoning to execution. The same connection creates a new class of reliability and security requirements. An unsafe answer is no longer the only failure mode; an unsafe action, delegation, memory write, tool call, or service publication can affect enterprise systems directly [7]. The central intuition is that agentic security is a path property. Language-agent methods such as ReAct interleave reasoning traces, actions, and observations, while cognitive-agent architectures explicitly model memory, action spaces, and decision processes [13, 12]. A final answer is reliable only when the sequence of actions that produced it is itself admissible. Capability is existential: it asks whether at least one execution can reach the goal. Reliability is universal over the events of the selected execution: every transition that converts reasoning into action must satisfy the governing invariants. The scientific objective is therefore not to reduce capability, but to maximize useful autonomy inside a reliability envelope. In this paper, reliability is used in a security and economic sense: an agentic action is reliable only when the runtime can explain who initiated it, which authority was used, which policy allowed it, which data or memory it touched, which human approval was required, which budget it con- sumed, which durable artifact or output state it produced, and which audit evidence remains after execution. The focus is therefore the transition between reasoning and action. This transition is where an LLM suggestion becomes an API call, a tool invocation, a sub-agent request, a memory update, or a published service response. If that transition is not governed, even a benign user request may produce unauthorized side effects or consume capital without delivering a recoverable result. Existing standards and frameworks provide important foundations. OWASP AISVS defines AI security verification categories that include input validation, access control, memory security, agentic action security, monitoring, privacy, and human oversight [1]. NIST AI RMF organizes enterprise AI risk management through Govern, Map, Measure, and Manage [2]. MAESTRO provides a layered threat model for agentic AI systems [4]. AgenticSecurity.info aggregates AISVS controls, NIST mappings, threat catalogs, mitigation catalogs, component taxonomies, architecture patterns, and threat-modeler outputs [6]. These resources help engineers identify what can go wrong and which controls may be relevant. However, assessment artifacts do not by themselves define execution semantics. Existing bench- marks and environments evaluate interactive task completion, web navigation, and agent decision- making, but their primary metrics are functional correctness or task success rather than enterprise authorization, auditability, or profile-preserving execution [9, 10, 11]. A platform still needs to decide whether an agent may be created, whether a user can attach a connector, whether a tool call should be denied or escalated, whether a memory source is visible under a caller’s role, whether a high-risk workflow requires human approval, whether a service published under one profile can be invoked by a caller under another profile, and whether a sub-agent can reduce the effective security posture of a call chain. These decisions must be made consistently at runtime, not only during design review. The research literature also shows that agentic security is not a single problem. Public testbeds 2 such as AgentDojo and Agent Security Bench evaluate prompt injection, tool abuse, memory poi- soning, and mixed attacks [26, 27]. Runtime defenses such as ClawGuard and DRIFT intercept or isolate unsafe tool-call behavior [28, 29]. NeuroTaint studies semantic information flow and cross-session persistence in agents [30]. Governance-oriented work such as AGENTSAFE and MI9 moves toward design-time, runtime, and audit controls [31, 32]. MCP security analyses identify protocol-specific risks such as capability attestation gaps, origin-authentication gaps, and implicit trust propagation [33]. These works are useful comparative references, but they are not treated as standards in this paper. Enterprises still require a compositional method that can place such controls inside a single runtime policy model. The paper addresses this gap through a policy algebra for trust-preserving agentic execution. The need for an execution-level model follows from prior work showing that agents can generate actions, call APIs or tools, maintain memory, and navigate large action spaces [13, 12, 15, 16]. The algebra treats security profiles as ordered policy objects. It resolves enterprise policy through a cas- cade from platform to team, user, agent, and publication scopes. It authorizes tools by intersecting role, agent, service-exposure, layer, data, budget, artifact-state, and approval predicates. It extends naturally to multi-agent execution by using profile joins, tool-set intersections, budget narrowing, memory-scope narrowing, artifact materialization, and human-approval propagation. The resulting runtime does not ask only whether an agent has a tool. It asks whether this caller, this agent, this service, this data class, this profile, this budget, this artifact state, and this approval state jointly permit this action. The motivating enterprise setting is practical. A platform may provide an agent framework, a runtime execution layer, and one or more applications. Users and teams create agents, attach knowledge sources, configure tools, expose services through MCP and REST interfaces, and invoke published agents from other applications. WebShop, AgentBench, and WebArena show that lan- guage agents can operate over web-like, tool-rich, and multi-step interactive environments, while Security of AI Agents shows that these capabilities expose confidentiality, integrity, and availabil- ity risks when actions are insufficiently constrained [9, 10, 11, 7]. In such an environment, local controls are insufficient. A profile selected in the UI must be reflected in backend enforcement. A permission gate must see user roles, agent allowlists, service-publication metadata, data classifica- tion, budget state, and artifact state. A service approval must freeze the security context under which the service was reviewed. A sub-agent cannot be allowed to launder a high-security call into a lower-security execution path. Consider an internal audit agent that can read invoices, compare purchase orders, query an ERP system, create exceptions, and request clarifications from another specialist agent. A conventional access-control layer may verify that the user can open the audit application, and a prompt guardrail may detect some malicious text. Prior work on protection systems and role-based access control motivates the access-control part of this requirement, while prompt-injection and jailbreak studies show why prompt-level defenses alone are insufficient for agentic execution [23, 25, 17, 18, 7]. The audit run also needs to know which invoice classes the user may inspect, whether the ERP query is read-only, whether the exception-creation tool is destructive, whether the specialist agent inherits the initiating user’s constraints, whether a high-value exception requires human approval, and whether the final answer exposes confidential supplier information. The security property is therefore not attached to one prompt or one API endpoint. It is attached to a chain of decisions. This chain perspective motivates four requirements. First, the runtime must treat policy as compositional. RBAC, profiles, tool allowlists, data classifications, publication metadata, artifact state, and human approvals must combine into one executable decision. Second, the runtime must be monotone across delegation. When a caller invokes another agent, the child context must not be less restrictive than the parent context. Third, the runtime must enforce bounded loss 3 for unattended execution, so budget exhaustion without a durable artifact is treated as a policy failure rather than merely an expensive run. Fourth, the runtime must produce evidence. These requirements reflect the fact that agent traces are not just text histories: they contain reasoning, tool calls, observations, memory accesses, and environment effects [13, 12, 14, 7]. If the system denies a tool call, redirects to artifact materialization, escalates to a human, redacts output, or freezes a publication profile, the decision should be visible in a trace that supports review and incident response. The proposed policy algebra does not require every platform to implement the same user in- terface or the same control mechanism. Instead, it defines the algebraic invariants that any im- plementation should preserve. Profiles form an ordered policy space. Delegation uses joins rather than overwrites. Tool authorization is a conjunction, not a single allowlist check. Memory access is governed by classification, scope, purpose, and retention. Publication creates a versioned se- curity snapshot. Cost-aware materialization creates a recoverable output obligation under budget pressure. Audit completeness is part of the feasibility of an execution, not an optional afterthought. The research question is therefore: How can an enterprise agent platform preserve useful agent capability while ensuring that every executed action remains authorized, non-amplifying under del- egation, economically recoverable, and auditable? The answer is obtained by compiling heteroge- neous guidance into executable predicates and composing those predicates into a reliability envelope that constrains, but does not otherwise replace, the agent’s task reasoning. This framing is consis- tent with prior evidence that language agents execute multi-step decisions in external environments, but it shifts the evaluation target from task success alone to the joint achievement of task success and admissible, auditable execution [10, 11, 7]. This question differs from conventional access control in two ways. First, the protected object is not only a resource such as a file or API. The protected object is often a transition: a model- generated proposal becomes an action under a particular identity, profile, memory state, artifact state, and call chain. Second, the authorization state is not static. Each step can change the remaining budget, memory scope, artifact state, approval state, and available evidence. A secure runtime must therefore evaluate policies repeatedly as the execution unfolds. The question also differs from ordinary workflow governance. In a traditional workflow, design- ers typically know the sequence of steps in advance. Classical planning assumes explicit models of actions and goals [8]. In an agentic workflow, however, the reasoner may propose the next tool call dynamically, as in reasoning-and-acting methods and multi-API planning methods [13, 15, 16]. The platform is not assumed to pre-enumerate every action path. Instead, every proposed path must pass through the same algebraic constraints. This makes the method suitable for both scripted workflows and adaptive agents. Finally, the paper distinguishes between assessment and enforcement. A threat model can say that a workflow has a tool-misuse risk. An enforcement model must decide whether the specific tool call should be allowed, denied, sandboxed, approved by a human, or logged with stronger evidence. This distinction is important because agent-security studies identify concrete vulnerabilities in sessions, model interaction, agent programs, prompt injection, and tool execution, but the runtime still needs an enforceable decision procedure for each proposed action [7, 17, 18]. The method connects these levels by mapping threat-model artifacts to policy predicates. The resulting runtime can use assessment outputs, but it does not stop at assessment. The paper makes four contributions. 1. A definition of reliable capability that distinguishes reaching a goal from reaching it through an admissible action path, and formulates agent autonomy as utility maximization inside a reliability envelope. 4 Update Memory Call Tool Or API Retrieve Documents Delegate Sub-Agent Publish Respond Or Write Enterprise Goal User Request Or Workflow Trigger LLM-Based Agent Reasons, Plans, And Proposes Actions Proposed Action Sequence Policy-Algebra Gate All Checks Must Pass Identity, Role, Profile, Data, Memory, Tool, Budget, Outcome, HITL, Audit Ungoverned Or Weakly Governed Path △ Unsafe Action △ Overbroad Access △ Delegation Laundering △ Budget Spent With No Outcome Governed Path ✓ Admissible Action ✓ Narrowed Authority ✓ Bounded-Loss Outcome ✓ Audit Evidence Figure 1: From output safety to action-path reliability. A chatbot-style assessment can focus on the final answer, but an agentic system must govern each reasoning-to-action transition. The proposed policy algebra admits actions only when identity, role, profile, data, memory, tool, budget, outcome, human-approval, and audit predicates jointly hold, thereby preventing unsafe actions and zero-outcome budget exhaustion. 2. A policy algebra that composes enterprise profiles, RBAC, tools, memory, publication, bud- get, approval, and evidence obligations. The composition is trust-preserving and is the least restrictive policy state satisfying all governing inputs. 3. Runtime semantics for non-amplifying multi-agent delegation and cost-aware artifact material- ization, including profile joins, authority intersections, budget narrowing, approval inheritance, and recoverable-output obligations. 4. A design-science path from security artifacts to executable predicates, a reference runtime, con- formance measures, capability–reliability trade-off analysis, and policy repair through regression testing. Figure 1 summarizes the proposed shift from output-only assessment to action-path reliability. To the best of our knowledge, this is an early implementation-oriented formalization that con- nects standards aggregation, enterprise profile governance, multi-agent trust propagation, MCP, REST publication control, RAG and memory security, and continuous verification inside one run- time semantics. The aim is not to replace existing standards or defenses. The aim is to make them executable in an enterprise agent platform. 5 2 Background and Related Work The related literature is best read as identifying risk surfaces rather than specifying a single en- forcement semantics. This section separates those two roles. 2.1 Agentic AI and Multi-Agent Systems Agency matters because a model output can become a state-changing operation. An agentic system contains one or more reasoning modules that can decompose tasks, call tools, retrieve data, update memory, and delegate work. This view extends the classical agent and multi- agent systems literature, where agents are treated as autonomous entities that perceive, decide, act, and interact with other agents in a shared environment [19, 20, 21, 22]. Agents may be sequential, hierarchical, reactive, collaborative, or knowledge-intensive. Once agents receive access to tools and memory, they become actors in an operational environment. This changes the security target from content filtering to governed action. Multi-agent systems add trust-chain complexity. A caller may invoke a sub-agent with a different tool set, publication profile, memory scope, or service exposure. Without explicit propagation rules, delegation can widen authority. Recent work on multi-agent trust describes the tension between collaboration and over-exposure [34]. This paper operationalizes that concern through monotone profile joins and narrowing of tools, budget, and memory. 2.2 Standards, Threat Models, and Aggregators Standards and threat models define what should be controlled; the runtime still has to decide how those controls compose. AISVS, NIST AI RMF, and MAESTRO provide complementary perspectives. AISVS defines verifiable security requirements [1]. NIST AI RMF organizes institutional risk management [2]. MAESTRO locates agentic risks across layers such as models, data operations, frameworks, tools, deployment, observability, and agent ecosystems [4]. AgenticSecurity.info combines these ideas with threat catalogs, mitigation catalogs, component taxonomies, architecture patterns, and threat- modeler outputs [6]. These artifacts serve as a knowledge substrate. 2.3 Runtime Defenses, Testbeds, and Governance Runtime defenses and testbeds supply useful cases and controls, but they do not by themselves define the enterprise policy state. Public testbeds such as AgentDojo and Agent Security Bench provide examples of adversarial prompt, tool, and memory conditions [26, 27]. ClawGuard and DRIFT focus on runtime defenses for indirect prompt injection and tool-boundary enforcement [28, 29]. NeuroTaint frames information flow for agents that transform and persist information across sessions [30]. AGENTSAFE and MI9 study broader governance and runtime assurance [31, 32]. MCP security work identifies risks in tool-integrated protocol settings [33]. The method is complementary, but its evaluation standard is the proposed policy algebra, control taxonomy, and conformance protocol rather than any single public testbed. 2.4 Agentic Identity and Access Management Identity is necessary but not sufficient; after authentication, execution authority must still be narrowed by profile, memory, tool, and publication constraints. 6 Agentic IAM work proposes decentralized identifiers, verifiable credentials, zero-knowledge proofs, agent naming services, and session enforcement for agent authentication and access con- trol [35]. Authentication and base authorization are assumed to be established. The focus is the execution layer: how policies constrain tools, memory, publication, budget, artifact production, approvals, and delegation after identity is known. 2.5 Cost-Aware Execution and Bounded-Loss Design Cost is also part of the execution context in unattended agentic systems. A workflow that consumes all allocated budget while producing no durable artifact may satisfy a simple spending cap, but it still fails as a governed execution because the platform has no recoverable output to return, inspect, or resume. This failure mode is especially important for asynchronous enterprise agents, where the user is not continuously supervising each reasoning step. The relevant risk-management literature emphasizes that systems operating under uncertainty should first avoid ruin-like states and unmanaged downside before optimizing expected gain [38, 37]. Taleb and Douady formalize antifragility in terms of payoff behavior under stress and volatility, distinguishing systems that are merely robust from systems whose payoff structure benefits from bounded perturbations [36]. In this paper, the corresponding runtime question is narrower and operational: can the platform prevent an execution trace whose cost is fully realized while its artifact state remains empty? The answer is a materialization predicate inside the same policy algebra used for tools, memory, budget, approval, and audit. The runtime allows research and planning while cost exposure remains acceptable. Once cost consumption becomes material and no artifact exists, the admissible action set is constrained toward producing a durable draft, checkpoint, file, record, or partial result. This makes bounded-loss behavior a platform-enforced property rather than a voluntary self-regulation behavior expected from the model. Table 1: Related work and gap addressed by this paper. No.Work or standardMain focus and contributionGap addressed by this paper 1OWASP AISVS [1]AI security verification through testable control categories and levels Action-level enforcement inside an agent loop 2NIST AI RMF and GenAI profile [2, 3] AI risk governance through the Govern, Map, Measure, and Manage cycle Runtime semantics for the risk cycle 3MAESTRO [4]Agentic threat modeling through layered analysis of agentic systems Translation from layer finding to policy gate 4MITRE ATLAS [5]AI adversary tactics and techniques for AI systems Runtime use of tactics as control requirements 5Agentic Security Hub [6] Aggregated standards, threats, components, architectures, and mappings Compilation into executable runtime constraints 6Agent and multi-agent systems foundations [19, 20, 21, 22] Autonomy, interaction, coordination, and multi-agent system design Runtime security semantics for tool-using agentic systems 7Public agent-security testbeds [26, 27] Comparative workloads for prompt, tool, memory, and mixed attack cases Optional comparison; conformance is defined by the proposed runtime predicates 8Agent Security Bench [27] Attack and defense testbed for prompt, tool, memory, backdoor, and mixed attacks Mapping attacks to control predicates and traces 7 No.Work or standardMain focus and contributionGap addressed by this paper 9ClawGuard [28]Tool-boundary defense through deterministic rule enforcement at tool calls Integration with profile, data, budget, and audit constraints 10DRIFT [29]Dynamic injection defense through rules and memory-stream isolation Integration with enterprise policy cascade 11NeuroTaint [30]Agent information-flow analysis using trace and memory-based taint tracking Formal memory/RAG predicates and assurance signals 12AGENTSAFE [31]Governance framework for lifecycle risk-to-control mapping Policy algebra and executable profile cascade 13MI9 [32]Runtime governance using risk index, telemetry, and authorization monitoring Trust algebra and publication-aware action control 14Agentic IAM [35]Agent identity through verifiable identity and access mechanisms Post-authentication execution control 15MCP security analysis [33] MCP protocol risk, including capability attestation and trust propagation Profile-capped MCP, REST publication governance 16Trust Paradox [34]Multi-agent trust and the exposure risk created by collaboration Monotonic trust rule and call-chain constraints 17Quantitative risk and antifragility [38, 37, 36] Downside control, fat-tail risk, and payoff behavior under uncertainty Cost-aware artifact materialization for bounded-loss unattended execution Source: Authors’ synthesis from cited studies 3 Problem Formulation: From Capability to Reliable Capability The basic distinction is between completing a task and completing it through an admissible path. A runtime that blocks every action may be safe but is not useful; a runtime that completes every task by any available means may be capable but is not trustworthy. Reliable capability requires both goal achievement and path admissibility. Capability alone can hide risk: an agent may answer correctly after reading data it should not access, call a tool that the user could not call directly, delegate to a weaker profile, write memory that changes future behavior, consume the full budget without producing a durable artifact, or complete a workflow without an audit trail. Reliability is therefore formulated as a property of the execution path, not only of the final answer. The execution trace is therefore the primitive object of analysis. Let an execution be a trace ξ = (s 0 ,a 0 ,o 0 ,s 1 ,a 1 ,o 1 ,...,s T ,a T ,o T ), where s t is the runtime state, a t is an action chosen by the agent runtime, and o t is the observation returned by a model, tool, memory system, service, or environment. An action may be an internal reasoning step, a tool call, a service invocation, a memory operation, a data retrieval, a publication action, or a delegation to another agent. The question is not only whether a t helps complete the task, but whether it is feasible under the governing security context. Let Ξ(g,ζ) be the set of traces that agent or service g can generate for task ζ. Definition 1 (Agent capability). Agent g is capable of task ζ if at least one executable trace reaches the task goal: Capable(g,ζ) ⇐⇒ ∃ξ ∈ Ξ(g,ζ) : GoalReached(ξ,ζ) = 1.(1) 8 Capability is therefore an existential property. It does not constrain the path by which the goal is reached. The security context at time t is modeled as c t = (u,g,p t ,R t ,K t ,B t ,H t ,L t ,O t ,A t ), where u is the initiating identity, g the agent or service, p t the effective security profile, R t the role and resource state, K t the memory and knowledge scope, B t the remaining budget, H t the human-approval state, L t the call-chain lineage, O t the durable artifact or checkpoint state, and A t the audit state. The symbol π t denotes the policy state induced by this context. Definition 2 (Action event). An action event is the tuple η t = (u,g,s t ,a t ,o t ,c t ,π t ). It binds the actor, agent or service, selected action, returned observation, runtime context, and effective policy state for a single reasoning-to-action transition. Definition 3 (Reliable agent execution). An execution ξ is reliable under policy state sequence π 0:T if every action event η t satisfies Id t ∧ Role t ∧ Prof t ∧ Data t ∧ Mem t ∧ Tool t ∧ Bud t ∧ Art t ∧ Hitl t ∧ Aud t = 1,(2) where the predicates denote identity validity, role authorization, profile compliance, data compliance, memory/RAG compliance, tool or service compliance, budget compliance, artifact materialization compliance, human-approval compliance, and audit completeness, respectively. For every delegation edge i→ j, the delegated context must also satisfy p i ⪯ p i→j , T i→j ⊆ T i ,Θ i→j ⊆ Θ i , B i→j ≤ B i .(3) where p i→j , T i→j , Θ i→j , and B i→j are the profile, tool set, memory scope, and budget assigned to the delegated call from i to j. Thus delegation may tighten the profile, narrow tools, narrow memory scope, and reduce budget, but it may not widen the authority inherited from the caller. Definition 4 (Reliable capability). Agent g is reliably capable of task ζ under policy sequence π 0:T if it can reach the goal through at least one reliable trace: ReliablyCapable(g,ζ,π 0:T ) ⇐⇒ ∃ξ ∈ Ξ(g,ζ) : GoalReached(ξ,ζ) = 1 ∧ Reliable(ξ,π 0:T ) = 1. (4) The goal condition is existential over traces, while reliability is universal over the action events in the selected trace. Reliable capability is consequently stronger than raw capability, but it does not require the runtime to reject actions that already satisfy every applicable constraint. Equation (2) states reliability as a conjunction of independent Boolean obligations. A single failed predicate makes the action unreliable. Equation (3) adds the multi-agent condition needed to prevent profile laundering and authority widening across call chains. 9 Let Narrow(a t ,c t ) = 1 when a t is not a delegation or when the delegation relation satisfies (3). The principal failure modes are indicator functions over these predicates: F id (t) = 1− Id t ,invalid or missing actor identity, F role (t) = 1− Role t ,role does not authorize the action, F profile (t) = 1− Prof t ,action violates the effective profile, F data (t) = 1− Data t ,data class or scope is not allowed, F mem (t) = 1− Mem t ,memory read, write, or retrieval is not allowed, F tool (t) = 1− Tool t ,tool or service call is not allowed, F budget (t) = 1− Bud t ,budget or rate limit is exceeded, F artifact (t) = 1− Art t ,cost exposure is high but no durable artifact exists, F trust (t) = 1− Narrow(a t ,c t ), delegation widens profile, tools, memory, or budget, F hitl (t) = 1− Hitl t ,required human approval is absent, F audit (t) = 1− Aud t ,required evidence is missing. (5) The aggregate failure score is F (ξ) = T X t=0 w 1 F id (t) + w 2 F role (t) + w 3 F profile (t) + w 4 F data (t) + w 5 F mem (t) + w 6 F tool (t) + w 7 F budget (t) + w 8 F artifact (t) + w 9 F trust (t) + w 10 F hitl (t) + w 11 F audit (t) . (6) where w i ≥ 0 is the relative weight assigned to the ith failure class. A hard-policy deployment sets the admissible region by requiring each failure term to be zero; a risk-scoring deployment may use the weighted sum only after hard feasibility has been checked. Reliable execution requires F (ξ) = 0 for hard security constraints and requires (3) for all delegation edges. This formulation gives a precise meaning to the failure cases considered in the rest of the paper: wrong authority is an identity or role failure, overbroad tools are tool failures or delegation violations, data leakage is a data failure, memory contamination is a memory failure, profile laundering is a delegation-profile violation, unrecoverable cost without output is an artifact-materialization failure, unapproved ex- ternal action is a HITL failure, and missing traceability is an audit failure. In deployments that permit risk scoring, F (ξ) can also serve as one input to the residual-risk model defined in the preliminaries. 3.1 Conditional Correctness and Context Perception The policy algebra decides over a structured execution context, but some context fields may be observed rather than intrinsically known. Let c t denote the correct context and bc t the context presented to the policy gate after tool metadata lookup, data classification, provenance checking, or semantic classification. End-to-end unsafe execution can arise either because the context was represented incorrectly or because the gate made an incorrect decision despite a correct context. By event decomposition, Pr(UnsafeAllowed)≤ Pr(bc t ̸= c t ) + Pr(UnsafeAllowed| bc t = c t ). (7) 10 The algebra and its conformance tests target the second term: conditional on correct identity, policy, tool, data, memory, budget, artifact, and approval facts, the decision procedure should preserve the stated invariants. The first term belongs to the observation and metadata boundary. It includes misclassified documents, ambiguous tool intent, stale service metadata, incomplete command classification, and missing action-risk tags. This separation prevents a deterministic policy guarantee from being confused with the accuracy of the systems that supply its facts, and it provides a direct interpretation for the residual failure modes reported in the evaluation. 4 System Model Profiles play the role of ordered risk regimes: moving upward in the order can only increase assur- ance obligations. Let P =Low, Medium, High, VeryHigh be a finite ordered set with Low⪯ Medium⪯ High⪯ VeryHigh. The order denotes increasing assurance and restriction. The join p i ⊔p j returns the more restrictive profile, and the meet p i ⊓ p j returns the less restrictive profile. Each profile is a policy object Γ(p) = (M p ,T p ,C p , Θ p ,τ p ,B p ,Q p ,H p ,E p ,S p ,A p ), where M p is the model set, T p the tool set, C p the admissible data classes, Θ p the memory-scope relation, τ p retention limits, B p budget, Q p artifact-materialization policy, H p approval predicate, E p external exposure policy, S p schema/determinism policy, and A p audit-depth requirement. The profile order represents assurance obligations, not an independent grant of business priv- ilege or data clearance. A higher profile may require stronger validation, isolation, approval, and evidence, but it cannot by itself authorize a tool or resource that the initiating identity, agent configuration, data policy, or publication state does not authorize. Effective authority is always obtained through the intersections defined below. This separation prevents stronger assurance from being misread as broader entitlement. LetI be the set of users, teams, service accounts, applications, MCP clients, workflows, agents, and published services. Let R be the set of tools, connectors, knowledge sources, memory stores, models, APIs, and service endpoints. The runtime maps (I,R,P) into decisions over actions. 5 Preliminaries The guiding requirement is monotonicity: adding governance context should never widen what an agent is allowed to do. The policy algebra rests on six security principles. First, when additional governance context is introduced, the resulting execution posture should only become equally or more restrictive. Sec- ond, when execution crosses an agent, service, or workflow boundary, delegated authority should narrow rather than expand. Third, an action should be executable only when all independent policy families agree, including identity, agent configuration, service exposure, data policy, budget, artifact materialization, threat-layer policy, and human approval. Fourth, approval and evidence obligations should propagate through a call chain, because a later delegation must not erase obliga- tions introduced earlier. Fifth, probabilistic risk estimates should guide ranking, review thresholds, and assurance investment, but they should not override hard policy feasibility. Sixth, budgeted unattended execution should have bounded loss: the runtime should remove paths that can spend 11 the full budget without leaving a recoverable artifact. These principles build on established ideas in protection systems, information-flow control, and role-based access control [23, 24, 25], but agentic systems require them to be stated over dynamic reasoning-to-action transitions rather than over static users and resources alone. Security principleAlgebraic control Runtime effect Monotone context governance can only tighten p eff = ⊔ i p i Profile floor no lower layer weakens policy Non-widening delegation child authority cannot expand T i ∩ T j , Θ i ∩ Θ j , minB Narrowed authority tools, memory, and budget shrink Independent agreement all policy families must pass ρ ∧ α ∧ σ ∧ μ ∧ δ ∧ β ∧ η Action gate one failed predicate blocks execution Obligation propagation approval and evidence persist h i ∨ h j , E i ∪ E j HITL and audit obligations survive call chains Hard-policy dominance risk cannot authorize violations Feasible(a,s,c,π) = 1 Feasible set risk ranks only allowed actions Bounded loss no full spend without artifact Materialize(ξ t ,C t ,B 0 ) = 1 Recoverable output high-cost runs must materialize Figure 2: Policy-algebra principles and runtime effects. The algebra maps governance principles to monotone operators over profile, tool authority, memory scope, budget, artifact materialization, approval, and evidence obligations, yielding runtime effects that preserve trust before each reasoning-to-action transition. 5.1 The Policy Algebra The algebra is constructed so that composition narrows authority, accumulates obligations, and preserves evidence requirements. LetU denote the universe of executable tools and services,S the universe of admissible memory and data scopes, Q the universe of artifact-materialization policies ordered by restrictiveness, and E the universe of audit evidence obligations. A runtime policy state is represented by the tuple π = (p,T, Θ,B,Q,h,E), where p ∈ P is the security profile, T ⊆ U is the executable tool/service authority, Θ ⊆ S is the admissible memory and data scope, B ∈R ≥0 is the remaining budget, Q ∈ Q is the artifact- materialization policy, h ∈ 0, 1 indicates whether human approval is required, and E ⊆ E is the set of evidence obligations that must be recorded. The algebraic order ⪯ alg is defined by π 1 ⪯ alg π 2 ⇐⇒ p 1 ⪯ p 2 ∧ T 2 ⊆ T 1 ∧ Θ 2 ⊆ Θ 1 ∧ B 2 ≤ B 1 ∧ Q 1 ⪯ Q Q 2 ∧ h 1 ≤ h 2 ∧ E 1 ⊆ E 2 . (8) where π 1 = (p 1 ,T 1 , Θ 1 ,B 1 ,Q 1 ,h 1 ,E 1 ) and π 2 = (p 2 ,T 2 , Θ 2 ,B 2 ,Q 2 ,h 2 ,E 2 ). Thus π 2 is at least as restrictive and at least as auditable as π 1 when it has a profile no weaker than π 1 , no additional tool authority, no broader memory scope, no larger budget, no weaker materialization policy, no weaker approval obligation, and no smaller evidence obligation. 12 Definition 5 (Policy composition). For two policy states π 1 = (p 1 ,T 1 , Θ 1 ,B 1 ,Q 1 ,h 1 ,E 1 ) and π 2 = (p 2 ,T 2 , Θ 2 ,B 2 ,Q 2 ,h 2 ,E 2 ), define their composition as π 1 ⊗ π 2 = (p 1 ⊔ p 2 , T 1 ∩ T 2 , Θ 1 ∩ Θ 2 , min(B 1 ,B 2 ), Q 1 ⊔ Q Q 2 , h 1 ∨ h 2 , E 1 ∪ E 2 ).(9) Here ⊗ denotes policy composition, ⊔ returns the stricter profile, ∩ narrows tool and memory authority, min(·) selects the smaller budget, ⊔ Q returns the stricter materialization policy, ∨ accu- mulates approval requirements, and ∪ accumulates evidence obligations. Lemma 1 (Algebraic closure and compositional laws). If π 1 and π 2 are valid policy states, then π 1 ⊗ π 2 is a valid policy state. Moreover, ⊗ is commutative, associative, and idempotent. Proof. Closure follows because p 1 ⊔ p 2 ∈ P, T 1 ∩ T 2 ⊆ U , Θ 1 ∩ Θ 2 ⊆ S, min(B 1 ,B 2 ) ∈R ≥0 , Q 1 ⊔ Q Q 2 ∈Q, h 1 ∨ h 2 ∈0, 1, and E 1 ∪ E 2 ⊆E . Commutativity, associativity, and idempotence follow componentwise from the corresponding properties of least-upper-bound join, set intersection, minimum, Boolean disjunction, and set union. Theorem 1 (Trust preservation under composition). For any two valid policy states π 1 and π 2 , π 1 ⪯ alg (π 1 ⊗ π 2 ) and π 2 ⪯ alg (π 1 ⊗ π 2 ). Consequently, policy composition cannot reduce profile assurance, add executable tools or services, broaden memory scope, increase budget, weaken artifact-materialization requirements, remove hu- man approval, or remove audit obligations. Proof. The least-upper-bound property gives p i ⪯ p 1 ⊔p 2 and Q i ⪯ Q Q 1 ⊔ Q Q 2 for i∈1, 2. Also T 1 ∩ T 2 ⊆ T i , Θ 1 ∩ Θ 2 ⊆ Θ i , and min(B 1 ,B 2 )≤ B i . Boolean disjunction satisfies h i ≤ h 1 ∨ h 2 , and set union satisfies E i ⊆ E 1 ∪ E 2 . Substituting these componentwise relations into (8) proves the result. Theorem 2 (Least-restrictive sound composition). Let π be any valid policy state satisfying π 1 ⪯ alg π and π 2 ⪯ alg π. Then π 1 ⊗ π 2 ⪯ alg π.(10) Consequently, π 1 ⊗ π 2 is the least upper bound of the two governing states: it satisfies both inputs without imposing restrictions that are not required by at least one input component. Proof. Because π is an upper bound, its profile and materialization components upper-bound both inputs; therefore p 1 ⊔p 2 ⪯ p and Q 1 ⊔ Q Q 2 ⪯ Q Q. Its tool and memory sets are subsets of both input sets, hence T ⊆ T 1 ∩ T 2 and Θ⊆ Θ 1 ∩ Θ 2 . Similarly, B ≤ B 1 and B ≤ B 2 imply B ≤ min(B 1 ,B 2 ); h 1 ≤ h and h 2 ≤ h imply h 1 ∨ h 2 ≤ h; and E 1 ⊆ E and E 2 ⊆ E imply E 1 ∪ E 2 ⊆ E. These componentwise relations establish (10) under (8). Definition 6 (Action feasibility). For an action a in state s under context c and policy state π, define Feasible(a,s,c,π) = Auth(a,c)∧ Tool(a,c,π)∧ Data(a,c,π) ∧ Budget(a,c,π)∧ Materialize(a,c,π)∧ Approval(a,c,π)∧ Evidence(a,c,π). (11) where Auth denotes identity and base authorization, Tool denotes tool or service admissibility, Data denotes data-class admissibility, Budget denotes budget feasibility, Materialize denotes cost-aware artifact materialization feasibility, Approval denotes satisfaction of human-approval requirements, and Evidence denotes availability of the required audit record. 13 Definition 7 (Admissible action set). For state s t , context c t , and policy state π t , define A adm (s t ,c t ,π t ) =a∈A : Feasible(a,s t ,c t ,π t ) = 1∧ Risk(a,s t ,c t )≤ ρ max (p t ).(12) The admissible set is the action space remaining after hard policy predicates and the profile- dependent risk ceiling have been applied. The set A adm is the reliability envelope. It separates the responsibility of the policy runtime from that of the reasoner: the runtime determines which actions are admissible, while the reasoner remains free to optimize task utility among those actions. Theorem 3 (Gate soundness and policy-relative maximal permissiveness). For a fixed state, con- text, policy state, and risk ceiling, the admissible-action definition has two properties: a∈A adm ⇒ Feasible(a,s,c,π) = 1,(13) Feasible(a,s,c,π) = 1∧ Risk(a,s,c)≤ ρ max (p)⇒ a∈A adm .(14) Thus the gate excludes policy-violating actions but does not exclude an action that satisfies the complete declared feasibility conjunction and risk ceiling. This is maximal permissiveness relative to the encoded policy, not a claim that the encoded policy is complete. Proof. Both implications follow directly from the set definition in (12). The qualification is neces- sary because incorrect or missing context predicates remain possible as described in (7). Lemma 2 (Hard-policy dominance). If a /∈A adm (s t ,c t ,π t ) because Feasible(a,s t ,c t ,π t ) = 0, then x t,a = 0 in any feasible solution of the controlled action-selection problem (31). Proof. The optimization constraints in (31) require Feasible(a,s t ,c t ,π t ) = 1 for every selected action with x t,a = 1. If Feasible(a,s t ,c t ,π t ) = 0, selecting a would violate this constraint. Therefore any feasible solution must set x t,a = 0. Utility, cost, and residual-risk terms affect only the ranking of actions that remain in A adm (s t ,c t ,π t ). 5.2 Profile Cascade The effective profile is the most restrictive profile induced by all applicable governance scopes. Enterprise governance appears at several scopes. For request context c, the effective profile is p eff (c) = p platform ⊔ p team ⊔ p user ⊔ p agent ⊔ p publication .(15) where p platform , p team , p user , p agent , and p publication are the profiles induced by platform policy, team policy, user policy, agent configuration, and publication approval, respectively. This equation means that any layer may tighten the execution posture, but no lower layer may loosen inherited constraints. Lemma 3 (Monotone profile resolution). If ⊔ is the least upper bound on (P,⪯), then adding a new governing scope to (15) cannot reduce the assurance level of the effective profile. Proof. For any p,q ∈ P, p ⪯ p⊔ q by definition of least upper bound. Repeated application over the cascade gives p eff ⪯ p eff ⊔ q for any additional governing profile q. 14 Algorithm 1 Profile cascade resolution Require: Ordered profiles from platform, team, user, agent, and publication scopes Ensure: Effective profile p eff 1: p eff ← p platform 2: for p in (p team ,p user ,p agent ,p publication ) do 3: p eff ← p eff ⊔ p 4: end for 5: return p eff 5.3 Policy-Intersected Tool Authorization A tool call is treated as a governed transaction, not as a permission attached only to an agent. A call (τ,θ) is permitted only when independent policies agree: Permit(τ,θ,c) = ρ(u,τ,R t )∧ α(g,τ )∧ σ(τ,p publication ,E p ) ∧ μ(τ,θ,L MAESTRO )∧ δ(τ,θ,C p )∧ β(τ,B t )∧ κ(τ,θ,Q t )∧ η(τ,θ,H t ).(16) Here τ is the tool or service being called, θ is its parameter vector, u is the initiating identity, and g is the agent or service context. The predicate ρ is RBAC permission, α the agent/workflow allowlist, σ service exposure policy, μ layer or threat-model policy, δ data policy, β budget admissibility, κ artifact-materialization admissibility, and η approval satisfaction. 5.4 RAG and Memory Access Retrieved context and memory are state variables in the execution path. Their use must therefore be admissible under the same policy state that governs tools. Let d∈D be a retrieved document or context fragment, and let m∈M be a proposed memory write. Admissibility is defined as a conjunction over classification, ownership, scope, purpose, and retention: Read p (u,g,d,c) = 1κ(d)⪯ C p ∧ u∈ ACL(d) ∧ scope(d)∩ Θ p (g)̸=∅∧ purpose(c)∈ Purpose p . (17) Write p (u,g,m,c) = 1κ(m)⪯ C p ∧ owner(m) = u ∧ scope(m)⊆ Θ p (g)∧ ttl(m)≤ τ p ∧ sanitize p (m) = m. (18) where κ(·) gives the data classification, C p is the maximum admissible class under profile p, ACL(d) is the access-control list for document d, scope(·) gives the business or memory scope, Θ p (g) is the scope allowed to agent g under profile p, Purpose p is the set of allowed purposes, owner(m) is the memory owner, ttl(m) is the memory time-to-live, τ p is the retention bound, and sanitize p is the profile-specific sanitization map. A context construction step is admissible only when Y d∈Context(a t ) Read p t (u,g,d,c t ) = 1, and a memory update is admissible only when Y m∈MemWrite(a t ) Write p t (u,g,m,c t ) = 1. Here Context(a t ) is the set of retrieved fragments used by action a t , and MemWrite(a t ) is the set of memory objects proposed for persistence by action a t . These formulations bind memory and RAG access to the same profile algebra used for tools. 15 Algorithm 2 Tool authorization under intersected policies Require: Tool τ , parameters θ, context c, policy set Π Ensure: Allow, Deny, or RequireApproval 1: if ρ(u,τ,R t ) = 0 then 2:return Deny 3: end if 4: if α(g,τ ) = 0 then 5:return Deny 6: end if 7: if σ(τ,p publication ,E p ) = 0 then 8:return Deny 9: end if 10: if μ(τ,θ,L MAESTRO ) = 0 then 11:return Deny 12: end if 13: if δ(τ,θ,C p ) = 0 then 14:return Deny 15: end if 16: if β(τ,B t ) = 0 then 17:return Deny 18: end if 19: if H p (τ,θ) = 1 and Approved(τ,θ,c) = 0 then 20:return RequireApproval 21: end if 22: return Allow 5.5 Trust-Preserving Delegation Delegation is a change of execution context. The delegated context must inherit restrictions rather than obtain fresh authority. When agent or service i invokes j, the child context is derived by p i→j = p i ⊔ p j ,(19) T i→j = T i ∩ T j ,(20) B i→j = min(B remaining i ,B j ),(21) H i→j (a) = H i (a)∨ H j (a),(22) Θ i→j = Θ i ∩ Θ j .(23) where p i and p j are the caller and callee profiles, T i and T j are their tool sets, B remaining i is the caller’s remaining budget, B j is the callee’s budget cap, H i and H j are approval predicates, and Θ i and Θ j are memory-scope relations. The profile join prevents profile laundering; the set intersections and minimum budget prevent authority expansion through delegation. Equation (21) is a per-edge cap. In a branching or concurrent call graph, per-edge narrowing alone is insufficient because several children could each be assigned the same remaining parent budget. Let J i (t) be the set of child calls opened by agent i at time t, let b i→j be the budget atomically reserved for child j, and let b local i be the amount retained for the parent. A budget- 16 conserving executor additionally enforces b local i + X j∈J i (t) b i→j ≤ B remaining i , b i→j ≤ B i→j .(24) This treats budget as a conserved execution resource: delegation may divide or reduce it, but parallelism cannot multiply it. Lemma 4 (Delegation cannot lower the effective profile). For any call i→ j, the delegated profile satisfies p i ⪯ p i→j and p j ⪯ p i→j . Proof. The result follows from (19) and the least-upper-bound property of ⊔. Lemma 5 (Delegation cannot amplify allocated budget). If every branching step satisfies (24), then the sum of budgets allocated to the parent and its immediate children does not exceed the parent’s remaining budget at that step. Proof. The claim is exactly the conservation inequality in (24). Reapplying it at every child recur- sively prevents any subtree from creating budget not allocated by its parent. Atomic reservation is required so concurrent children cannot reserve the same units. 5.6 Multi-Agent Extension The multi-agent case is obtained by applying the same monotone rule along a call path. Let a multi-agent call graph be G = (V,E), where V is the set of agents or services and E contains directed calls. For a path π = (v 0 ,v 1 ,...,v k ), the path profile and tool authority are p(π) =⊔ k ℓ=0 p v ℓ , T (π) = k \ ℓ=0 T v ℓ . where p v ℓ is the profile at node v ℓ and T v ℓ is the tool authority at that node. The path profile p(π) is the strictest profile appearing on the path, and T (π) is the common tool authority available to all nodes on the path. The path is admissible if Depth(π)≤ D max , T (π)̸=∅ for required actions, k _ ℓ=0 H v ℓ (a)⇒ Approved(a,π). Here Depth(π) is the call depth, D max is the maximum permitted depth, H v ℓ (a) is the approval requirement for action a at node v ℓ , and Approved(a,π) is the approval evidence attached to the path. 5.7 Residual Risk Model Risk is used to rank feasible actions, not to relax hard feasibility constraints. The objective in the next subsection uses a risk term, but the runtime does not rely on an opaque scalar. Risk is decomposed by threat class. Let Z = z 1 ,...,z m be the set of threat categories, for example the T1–T15 categories from the Agentic Security Hub. For an action a in state s and context c, the risk decomposition uses four quantities, where q z (a,s,c) ∈ [0, 1] is the conditional likelihood that threat z is relevant or materializes for the action; I z (a,s,c)∈R r ≥0 is the impact vector, for example confidentiality, integrity, availability, privacy, compliance, and business 17 Algorithm 3 Evaluate a multi-agent call chain Require: Call path π = (v 0 ,...,v k ), action a, maximum depth D max Ensure: Derived path context or denial 1: if k > D max then 2:return Deny 3: end if 4: p π ← p v 0 ; T π ← T v 0 ; B π ← B remaining v 0 ; h π ← H v 0 (a) 5: for ℓ = 1 to k do 6: p π ← p π ⊔ p v ℓ 7: T π ← T π ∩ T v ℓ 8: B π ← min(B π ,B v ℓ ) 9: h π ← h π ∨ H v ℓ (a) 10: end for 11: if T π lacks a required tool for a then 12:return Deny 13: end if 14: if h π = 1 and Approved(a,π) = 0 then 15:return RequireApproval 16: end if 17: return (p π ,T π ,B π ,h π ) impact; ω ∈R r ≥0 is the enterprise impact-weight vector; and ψ z (a,s,c) ∈ [0, 1] is the residual exposure after active controls are applied. The residual risk of an action is Risk(a,s,c) = X z∈Z q z (a,s,c) ω ⊤ I z (a,s,c) ψ z (a,s,c).(25) where z indexes a threat class in Z, q z (a,s,c) is the likelihood term, ω ⊤ I z (a,s,c) is the scalarized impact, and ψ z (a,s,c) is the residual exposure after controls are applied. The residual exposure term is profile-dependent because profiles activate controls: ψ z (a,s,c) = Y m∈C(a,c,p eff ) (1− ε z,m ),(26) whereC(a,c,p eff ) is the set of controls active for action a under the effective profile, and ε z,m ∈ [0, 1] is the estimated effectiveness of control m against threat z. For example, sandboxing reduces residual exposure for unexpected code execution, HITL reduces exposure for high-impact external actions, and memory scoping reduces exposure for memory poisoning or data leakage. This formulation separates four quantities that are often collapsed incorrectly: threat likelihood, impact, active controls, and residual exposure. It also makes estimation practical. Initial values can be obtained from threat-modeler mappings, action type, tool criticality, data classification, architecture pattern, call depth, external exposure, and profile level. A simple estimator may use bq z (a,s,c) = σ θ ⊤ z φ(a,s,c) ,(27) where σ(·) is a link function, θ z is the parameter vector for threat class z, and φ(a,s,c) contains features such as tool type, data class, caller role, service exposure, memory scope, and whether the 18 action has external side effects. When historical telemetry exists, the likelihood can be updated with incident and red-team evidence, for example with a beta-binomial update: bq z,t+1 = α z + n event z,t α z + β z + n trial z,t .(28) where α z and β z are prior parameters for threat class z, n event z,t is the number of observed events by time t, and n trial z,t is the corresponding number of trials or opportunities for that threat class. The exact estimator is implementation-dependent; the algebra requires only that risk be decomposed into estimable components. Hard security requirements remain in Feasible(·) and Permit(·), so an imprecise risk estimate cannot authorize an action that violates policy. Risk is used to rank feasible alternatives, set review thresholds, and prioritize controls. 5.8 Valid Artifacts and Recoverability Artifact existence alone is too weak for bounded-loss execution: an empty file or unusable checkpoint should not satisfy the materialization obligation. Let o be a candidate artifact and let Q be the applicable materialization policy. Define ValidArtifact(o,Q) = Durable(o)∧ Nontrivial(o,Q)∧ SchemaValid(o,Q) ∧ Provenanced(o,Q)∧ Resumable(o,Q). (29) The exact tests are profile- and workflow-specific. A ticket may require a persisted identifier and status; a report may require a nonempty validated schema and source references; a checkpoint may require sufficient state to resume without repeating the full consumed cost. In the algorithms below, Artifact(ξ t ) is shorthand for the existence of an artifact that satisfies the operational validity checks configured by Q t . A stronger materialization deployment can reserve the cost of producing such an artifact. Let R Q (s t ) be a conservative upper bound on the cost of at least one available materialization action from state s t . A non-materializing action a t is budget-admissible only if C t + cost(a t ) + R Q (s t+1 )≤ B 0 .(30) Threshold-based redirection in Algorithm 5 is a practical approximation of this reserve rule when a workflow-specific cost bound is unavailable. Theorem 4 (Reserved capacity for recoverable execution). Assume cost estimates upper-bound realized action cost, reserve updates are atomic, and at least one artifact-producing action costing no more than R Q (s t ) remains available. If every non-materializing action satisfies (30), then open- ended execution cannot consume the capacity reserved to attempt a valid artifact. Proof. After any admitted non-materializing action, (30) leaves at least R Q (s t+1 ) of the initial budget unconsumed. By assumption, an artifact-producing action can be attempted within that reserve. The theorem preserves capacity to attempt materialization; artifact success still depends on the materializer and storage boundary and is therefore recorded as an explicit operational assumption rather than inferred from budget alone. 5.9 Controlled Action Selection Autonomy is modeled as optimization over the admissible set in (12). Utility matters only after the policy constraints are satisfied. 19 The runtime receives candidate actions from a reasoner and chooses among actions inA adm (s t ,c t ,π t ). Let x t,a ∈0, 1 denote whether action a is selected at step t, and let π t be the policy state induced by the effective context at that step. The execution objective is max x t,a T X t=0 X a∈A u(a,s t )− λRisk(a,s t ,c t ) − γcost(a) x t,a (31) s.t. X a∈A x t,a = 1, ∀t, Feasible(a,s t ,c t ,π t ) = 1, ∀(t,a) : x t,a = 1, Risk(a,s t ,c t )≤ ρ max (p t ), ∀(t,a) : x t,a = 1, X t,a cost(a)x t,a ≤ B p 0 , Materialize(ξ t ,C t ,B p 0 ,Q t ) = 1, ∀t, F (ξ) = 0, x t,a ∈0, 1. where u(a,s t ) is the task utility of action a in state s t , λ and γ are non-negative weights on risk and cost, cost(a) is the resource cost of action a, ρ max (p t ) is the maximum admissible risk under profile p t , B p 0 is the initial profile budget, C t = P t ℓ=0 P a∈A cost(a)x ℓ,a is cumulative consumed cost, and Q t is the applicable artifact-materialization policy. The feasibility and risk constraints are equivalent to requiring any selected action to lie in A adm (s t ,c t ,π t ). The objective states the semantics of governed autonomy. The agent may pursue utility, but only inside the feasible region defined by the policy algebra. The threshold ρ max (p t ) is stricter for higher-assurance profiles and can be set conservatively when risk estimates are immature. The budget constraint prevents overspend, but it does not by itself guarantee a useful payoff. A run can respect the cap and still end with no durable artifact. The materialization constraint prevents this zero-deliverable exhaustion state. Let Artifact(ξ t ) = 1 denote that the trace up to step t has produced a durable and recoverable artifact satisfying the operational checks associated with (29), such as a draft, checkpoint, file, ticket, record, or resumable intermediate state. The predicate Materialize(ξ t ,C t ,B p 0 ,Q t ) is satisfied when a valid artifact already exists, when cost consumption remains below the materialization threshold, or when the selected action is artifact-producing. Thus Budget(·) prevents overspend, while Materialize(·) prevents spending the available budget without leaving a recoverable output. This mechanism is a stop-loss rather than a workflow prescription. The runtime does not require the model to write before it has enough information. It allows research, retrieval, and planning while cost exposure remains acceptable. Once cost exposure becomes material and no artifact exists, the admissible action set is redirected toward producing a recoverable draft or checkpoint before further open-ended reasoning. 5.10 Consequences of the Algebra Lemma 6 (Human approval cannot be bypassed by delegation). If an action a requires approval at any node on a call path π, then Algorithm 3 returns RequireApproval unless approval evidence is present. 20 Algorithm 4 Governed execution loop Require: Request, caller identity, agent configuration, policy set Π Ensure: Response and audit trace 1: Authenticate caller and load RBAC context 2: p eff ← Algorithm 1 3: Initialize trace, call-chain metadata, memory scope, and budget 4: while not terminated do 5:Build context using (17) 6:Generate candidate action from an allowed model M p eff 7:if candidate is a tool call then 8:Apply Algorithm 2 9:else if candidate is an agent or service call then 10:Apply Algorithm 3 11:else if candidate is a memory write then 12:Enforce (18) 13:end if 14:Apply Algorithm 5 using current cost, budget, artifact state, and proposed action 15:Execute only if the selected action is feasible; otherwise deny, request approval, or ask for an alternative 16:Record audit evidence for identity, profile, policy decision, data class, approval, cost, and result 17: end while 18: Classify and redact output according to p eff 19: Persist trace and return response Proof. The path approval flag h π is the disjunction of all node-level approval predicates. If any node requires approval, h π = 1. The algorithm checks approval before returning an executable context. Lemma 7 (Tool authority narrows along a call path). For any path π = (v 0 ,...,v k ), T (π) ⊆ T v ℓ for every ℓ. Proof. The path tool set is the intersection of all tool sets on the path. 6 Enterprise Runtime Architecture The architecture is a realization of the algebra, not a separate source of security. Its purpose is to place each predicate on an enforceable runtime boundary. The algebra is implemented as a platform architecture rather than as a standalone checker. The architecture separates three concerns: a framework layer containing reusable blueprints and patterns, a runtime execution layer containing the system of record, and an application layer containing user interfaces, workflow builders, MCP clients, REST clients, and tenant applications. This separation keeps reusable agent design patterns distinct from production enforcement. Core platform services include an agent registry, profile and RBAC management, orchestration, tool and connector registries, knowledge and RAG services, memory management, publication and service governance, audit, monitoring, cost governance, artifact-state tracking, and deployment controls. Cross-cutting controls include RBAC/IAM, policy enforcement, audit and compliance, 21 Algorithm 5 Cost-aware artifact materialization Require: Trace ξ t , cumulative cost C t , budget B 0 , proposed action a t , thresholds α,β with 0 < α < β < 1 Ensure: Allow, redirect, restrict, or stop decision 1: r t ← C t /B 0 2: hasArtifact ← Artifact(ξ t ) 3: if C t ≥ B 0 ∧ hasArtifact then 4:return StopSuccess 5: else if C t ≥ B 0 ∧¬hasArtifact then 6:return StopFailure 7: else if hasArtifact then 8:return Allow 9: else if r t < α then 10:return Allow 11: else if α≤ r t < β then 12:return RedirectToMaterialize 13: else if r t ≥ β∧ ProducesArtifact(a t ) then 14:return Allow 15: else 16:return RestrictToArtifactWrite 17: end if risk and threat management, budget and quota enforcement, artifact materialization, privacy and data protection, human approval, and continuous verification. The cost-governance and artifact-state services are evaluated jointly. Budget enforcement records actual cost at each reasoning step, tool call, model call, and workflow node. Artifact- state tracking records whether the run has produced a durable and recoverable output, such as a draft document, checkpoint, file, database record, ticket, or resumable intermediate state. A run that has consumed substantial budget but has no artifact is not treated as merely expensive; it is treated as an unsafe payoff state. The platform therefore constrains the next admissible actions toward materialization before allowing additional open-ended research or planning. This distinction matters for unattended workflows. In a terminal-based coding assistant, the human developer can observe the run and interrupt it. In an asynchronous enterprise workflow, the system must be the governor. The runtime, not the model, enforces the stop-loss. 22 Security guidance AISVS, NIST, MAESTRO threats and patterns Enterprise context identity, RBAC, team user, agent, publication Runtime metadata tools, data, memory services, budget, artifact, HITL Policy composition Profile cascade p eff =⊔ i p i Authority narrowing T i ∩ T j , Θ i ∩ Θ j , minB Obligation inheritance HITL and audit evidence monotone by construction Effective policy state π t = (p,T, Θ,B,Q,h,E) Action gate Id ∧ Role ∧ Prof ∧ Data Mem ∧ Tool ∧ Bud ∧ Art HITL ∧ Aud Decision Deny and log Require approval Execute constrained Trace and repair lineage, cost, artifact, failed predicate Figure 3: Runtime enforcement flow for the policy algebra. Standards, threat findings, enterprise context, and runtime metadata are compiled into a monotone policy state. Each proposed action is admitted only when the identity, role, profile, data, memory, tool, budget, artifact-materialization, approval, and audit predicates jointly hold; denials, approvals, redirects, and executions all emit trace evidence for repair and regression testing. Table 2: Security profile semantics used by the runtime. No.ProfileModels/toolsMemory/dataApprovalAudit/budget 1LowSafe defaults; built-in tools Short-lived memory; no sensitive RAG None by defaultBasic logs 2MediumApproved models/tools; limited connectors Retention, redaction, classified RAG Destructive actions Tool parameters, costs, per-run budget 3HighWhitelisted tools/connectors Limited memory; vector decay; strict classes External side effects and writes Step traces, rate limits, anomaly detection 4VeryHighDeterministic tools for regulated actions Sanitized knowledge only; strict retention All regulated/ex- ternal actions Immutable evidence, fixed budgets, alerts 6.1 Implementation Sketches The following snippets show how a runtime may compile the algebra into concrete enforcement artifacts. The placeholders marked <> indicate deployment-specific values. Listing 1: Profile configuration sketch. profiles: high: allowed_models: [<approved-models>] allowed_tools: [<tool-ids>] data_classes: [internal, confidential] memory: retention_days: <N> cross_session: false vector_index: profile_scoped hitl: 23 required_for: [external_write, destructive_action] audit: depth: step_level evidence: [identity, profile, policy, tool, params_hash, approval, cost] Listing 2: Permission-gate sketch. def permit(tool, params, ctx): checks = [ role_permitted(ctx.user, tool), agent_allows(ctx.agent, tool), service_exposed(ctx.publication, tool), layer_policy_ok(tool, params, ctx.maestro_layer), data_policy_ok(params, ctx.profile), budget_ok(tool, ctx.budget), approval_ok(tool, params, ctx.hitl_state), ] if all(checks): return Allow() if approval_required(tool, params, ctx.profile): return RequireApproval(reason=<policy_reason>) return Deny(reason=<failed_predicate>) Listing 3: Audit-event sketch. "run_id": "<run>", "actor": "<user-or-service-account>", "agent_id": "<agent>", "effective_profile": "High", "action": "<tool-or-service-call>", "policy_decision": "RequireApproval", "data_class": "<classification>", "approval_id": "<approval-record>", "budget_before": "<amount>", "budget_after": "<amount>", "trace_parent": "<parent-step>", "result_hash": "<hash>" 7 Threat-to-Control Mapping Threat findings become useful only when they are converted into predicates, profile floors, and evidence obligations. Let F threat be the set of threat-model findings. For each finding f ∈F threat , define the threat- policy compiler Γ threat (f ) = (m f ,p f ,g f ,e f ),(32) where m f is the selected mitigation family, p f ∈P is the minimum profile required for the affected action, g f is the executable runtime gate or predicate, and e f ⊆E is the evidence set that must be recorded when the gate is evaluated. The runtime evaluates g f before the affected action executes 24 Table 3: Reference implementation status. No.ComponentImplementation status 1Security profiles and cascadeImplemented in configuration and UI; formal semantics defined in (15) 2Policy-intersected tool autho- rization Implemented in permission gate and executor paths 3Trust boundary propagationImplemented for profile and depth; formal verification remains future work 4Human approval inheritanceImplemented for core paths; asynchronous workflow queues un- der development 5RAG and memory governanceClassification and access checks exist; advanced cross-session re- tention remains partial 6Publication profile freezingImplemented using publication snapshots and review triggers 7Audit and observabilityBaseline metadata exists; immutable storage and richer anomaly detection remain future work 8Infrastructure controlsImplemented through Kubernetes/EKS hardening, mTLS, OPA, secrets, and encrypted stores and records e f for allow, deny, and approval outcomes. For example, an unexpected remote-code- execution finding for an agent using KC6 operational-environment components yields a sandboxing mitigation, command allowlist, network isolation, a High or Very High profile floor, denial or approval before execution, and audit evidence for actor, command, sandbox, approval state, and profile. Table 4: Threat-to-control mapping with explicit runtime controls and audit evidence. No.ThreatLayersAISVScate- gories ComponentsRuntime controlsAudit evidence 1Memory poison- ing Data,frame- work, observ- ability C8, C12Memory, RAG, tools Save/publish/run validation;re- trievalaudit; classification; retention limits Source ID, classi- fier result, retrieval hash, action result 2Tool misuseTools, runtimeC5, C9, C12Toolintegra- tion, runtime Intersected permission; sandbox; schema validation; HITL Tool, params hash, policy predicates, approver, cost 3Privilege compro- mise Framework, ecosystem C5, C9, C10Orchestration, runtime RBAC; cascade; monotone trust; depth limits Caller,callee, profile join,de- nied/escalated reason 4Resourceover- load Runtime,ob- servability C12RuntimeToken/cost bud- gets; rate limits; loop controls Budgetbe- fore/after,rate decision,loop counter 5Overwhelming HITL Framework, ecosystem C13OrchestrationRisk-adaptive approval; batch- ing; deterministic tools Approvalqueue state,decision latency, approver 6Unexpected RCETools, runtimeC4, C5, C9Toolintegra- tion, runtime Sandbox;com- mandallowlist; network blocking Commandhash, sandbox ID, net- work policy, result 25 8 Evaluation Methodology The evaluation is organized around conformance rather than benchmark ranking. A runtime is evaluated by asking whether the required predicates fire and whether the resulting trace contains sufficient evidence. The paper reports a preliminary design evaluation and defines a reproducible runtime evalu- ation protocol for the proposed policy-algebra standard. It does not treat any public benchmark suite as the source of validity. Instead, validity is defined by conformance to the proposed con- trol taxonomy, policy invariants, executable predicates, and evidence requirements. The runtime results in Section 11 evaluate the proposed policy-algebra runtime against an RBAC-and-allowlist comparator using the same workload, metrics, and scenario categories. As the conformance work- load, adversarial cases, and production-like service-publication traces expand, the same tables and metrics can be updated with the latest measured values. The evaluation therefore separates design coverage, runtime enforcement, adversarial scenarios, and policy repair. Map artifacts to controls Exercise conformance traces Measure decisions and evidence Repair policies and tests Coverage intervention rates trust violations audit completeness failed traces become stronger gates and regression cases Figure 4: Conformance evaluation and repair protocol for governed agents. The evaluation maps security artifacts to executable controls, exercises conformance traces, measures decisions and evidence, and converts failed traces into stronger gates and regression cases. Event-level details such as trace identifier, decision, failed predicate, profile, tool or service, approval state, budget, and latency are recorded in the trace rather than crowded into the diagram. The evaluation addresses seven research questions. 1. RQ1: Coverage. Does each standard control, threat class, component class, and architecture pattern map to at least one executable runtime control? 2. RQ2: Compilation. Does each mapped control compile into a runtime predicate, gate, audit field, profile floor, or regression test? 3. RQ3: Tool control. Does the permission gate block unsafe tool execution paths in the test protocol? 4. RQ4: Delegation. Does the trust algebra prevent profile downgrades and profile laundering in multi-agent calls? 5. RQ5: Evidence. Does the audit layer record enough data to reconstruct the actor, profile, tool or service, source, approval state, and policy decision? 6. RQ6: Bounded-loss execution. Does cost-aware artifact materialization reduce executions in which budget is exhausted without a durable output? 7. RQ7: Repair. Can failed evaluation cases be converted into policy updates and regression tests? 26 Hypothesis 1 (Coverage). The proposed control taxonomy maps each standard control, threat class, component class, and architecture pattern considered in the evaluation to at least one executable runtime control. Hypothesis 2 (Compilation). Each mapped security artifact can be compiled into at least one runtime predicate, gate, audit field, profile floor, or regression test. Hypothesis 3 (Tool-control effectiveness). Policy-intersected authorization will detect unsafe tool and service invocations that are missed by single-layer authorization mechanisms such as RBAC- only, service-exposure-only, or tool-allowlist-only enforcement. Hypothesis 4 (Delegation control). A runtime that enforces profile joins, tool intersections, memory-scope intersections, budget narrowing, and HITL inheritance will produce fewer trust- widening violations than a runtime using independent RBAC checks and tool allowlists alone. Hypothesis 5 (Audit reconstruction). Executions that emit evidence for identity, profile, policy decision, data class, approval state, budget state, artifact state, call-chain lineage, and result hash will support more reproducible governance review than executions with run-level logging only. Hypothesis 6 (Artifact materialization). A runtime that enforces cost-aware materialization thresh- olds will produce fewer zero-artifact budget-exhaustion failures than a runtime that enforces budget limits only. Hypothesis 7 (Policy repair). Failed evaluation cases can be converted into policy updates and regression tests. Table 5: Mapping from research questions and hypotheses to evaluation evidence. Research question HypothesisMetric, equation, or evidenceEvaluation location RQ1H1: CoverageCoverage(F,C) in Eq. (34); design-coverage matrix Section 9 RQ2H2: Compilationmapped(f i ) in Eq. (33); runtime predicate, gate, audit-field, profile-floor, or regression- test mapping Section 9 RQ3H3: Tool controlUnsafe intervention rate and false interven- tion rate in Eq. (35) and Eq. (36); governed tool-call protocol Section 10; Section 11 RQ4H4: DelegationTrust violation rate in Eq. (37); profile- monotonicity violations Section 10; Section 11 RQ5H5: EvidenceAudit completeness in Eq. (38); trace recon- struction fields Section 11 RQ6H6: Artifact mate- rialization Zero-artifact exhaustion rate; materializa- tion redirects and artifact-state evidence Section 10; Section 11 RQ7H7: RepairPolicy update and regression-update rules in Eq. (40) and Eq. (41) Section 12 Source: Authors’ formulation Let F = f 1 ,...,f n be the set of security artifacts to be checked. In this paper, F contains AISVS categories, NIST AI RMF functions, MAESTRO layers, T1–T15 threat classes, KC1–KC6 27 component classes, and architecture patterns. Let C =c 1 ,...,c m be the set of executable runtime controls. A finding f i is mapped if at least one runtime control enforces, monitors, or records it: mapped(f i ) = ( 1, ∃c j ∈ C : enforces(c j ,f i )∨ monitors(c j ,f i )∨ audits(c j ,f i ), 0, otherwise. (33) where enforces(c j ,f i ) means that control c j blocks or permits behavior associated with finding f i , monitors(c j ,f i ) means that the control observes the relevant behavior, and audits(c j ,f i ) means that the control records evidence for it. The design coverage score is Coverage(F,C) = 1 |F| |F| X i=1 mapped(f i ).(34) where|F| is the number of artifact classes being checked. The score is one only when every artifact class has at least one mapped enforcement, monitoring, or audit path. Coverage is not proof of security. It states whether the runtime has at least one control path for each item. Runtime testing is needed to check whether the control fires under adversarial execution. For runtime evaluation, let A unsafe be the set of actions that violate at least one policy predicate and let A safe be the set of actions that should be allowed. An intervention is any decision that prevents immediate unrestricted execution: denial, required approval, sandboxing or restriction, or redirection to artifact materialization. Equivalently, an intervention occurs when δ(a) ̸= Allow. The unsafe intervention rate and false intervention rate are UnsafeInterventionRate = |a∈ A unsafe : δ(a)̸= Allow| |A unsafe | ,(35) FalseInterventionRate = |a∈ A safe : δ(a)̸= Allow| |A safe | ,(36) where δ(a) is the runtime decision for action a, A unsafe is the set of policy-violating actions, and A safe is the set of actions expected to be allowed. Intervention is intentionally broader than denial because approval and materialization decisions are central behaviors of the proposed runtime; scenario-level results should therefore be read as immediate execution prevented or constrained, not necessarily as permanent rejection. For a delegation chain g 0 → g 1 → · → g k with effective profiles p 0 ,...,p k , the trust violation rate is TrustViolationRate = |i∈0,...,k− 1 : p i+1 ≺ p i | k .(37) where g i is the ith agent or service on the chain, p i is its effective profile, and p i+1 ≺ p i denotes a strict profile downgrade. A correct implementation of the monotonic trust rule should have TrustViolationRate = 0. For audit evidence, let R(e) be the required audit fields for event e and let L(e) be the logged fields. Audit completeness is AuditCompleteness = |e∈ E : R(e)⊆ L(e)| |E| .(38) where E is the event set, R(e) is the required evidence set for event e, and L(e) is the set of fields actually logged for that event. 28 For bounded-loss execution, let R be the set of completed or stopped runs, let Exhausted(r) indicate that run r consumed its available budget, and let Artifact(r) indicate that run r produced a durable recoverable output. The zero-artifact exhaustion rate is ZeroArtifactExhaustionRate = |r ∈R : Exhausted(r)∧¬Artifact(r)| |r ∈R : Exhausted(r)| .(39) A correct materialization implementation should drive this rate toward zero by redirecting or re- stricting actions before budget exhaustion. The evaluation produces three outputs: a coverage matrix, a set of weakly covered or uncovered cases, and a set of policy repair actions. These outputs feed back into the policy set. A failed case becomes a stricter profile floor, a narrower tool allowlist, a new HITL rule, a memory access restric- tion, a service-publication review, a materialization threshold update, a new audit requirement, or a new regression test. 9 Preliminary Design Evaluation The design evaluation asks whether the algebra has a control surface for each class of security artifact. The preliminary design evaluation checks whether the proposed runtime has an executable control path for each artifact class. It is separate from the runtime measurements reported in Section 11. The aim here is narrower: verify whether the policy algebra has enough control surfaces to support runtime tests. Table 6: Preliminary design coverage of security artifacts by runtime controls. No.Artifact familyCoverage criterionRuntime control path 1AISVS categoriesEach category maps to an enforcement or audit surface Profile rules, input validation, output filtering, memory policy, tool gate, audit schema 2NIST AI RMF functions Each function maps to a lifecycle or runtime mechanism Governance cascade, asset mapping, monitoring, policy repair 3MAESTRO layersEach layer maps to one or more runtime controls Model gateway, RAG gate, tool gate, sandbox, observability, trust chain 4T1–T15 threat classes Each threat maps to a control, evidence field, and test case Threat-to-control matrix, profile floor, HITL, monitoring, trace field 5KC1–KC6 components Each component maps to scoped runtime constraints Model, orchestration, memory, tool, and operational policies 6Agent architecture patterns Each pattern maps to profile floors and delegation constraints Sequential, hierarchical, swarm, reactive, and RAG agent policies Source: Authors’ design evaluation The next check evaluates whether the central invariants of the algebra are represented in the policy algebra and in the implementation design. 29 Table 7: Preliminary evaluation of policy-algebra invariants. No.InvariantFormal conditionRuntime mechanism 1Profile monotonicity p i ⪯ p i→j for delegated executionProfile cascade and profile join 2Tool authorizationPermit(τ,θ,c) = 1 before execution Intersected permission gate 3HITL inheritance H i→j (a) = H i (a)∨ H j (a)Approval propagation over the call chain 4Budget narrowing B i→j ≤ B i Budget attribution and sub-budget allocation 5Artifact materialization Materialize(ξ t ,C t ,B p 0 ,Q t ) = 1Cost-governance and artifact-state gate 6Publication freeze p publication participates in p eff until review Published service profile snapshot 7RAG access controlRead p (u,g,d,c) = 1 for retrieved context Save-time, publish-time, and run-time validation 8Audit completeness R(e)⊆ L(e) for each eventAudit schema and trace logger Source: Authors’ design evaluation This preliminary design evaluation identifies three remaining gaps. First, a mapped control does not prove attack resistance. A predicate may exist but still fail to fire under some execution path. Second, the policy algebra assumes correct metadata for tools, data sources, memory items, and services. A misclassified tool or data object can weaken enforcement. Third, semantic influence through memory and retrieval can persist even when exact text is filtered. These gaps motivate the runtime evaluation protocol in Section 10. 10 Runtime Evaluation Protocol The runtime protocol turns the algebra into testable action events. The runtime protocol defines executable conformance tests for the runtime. It is intended for execution against the authors’ conformance workload, internal red-team cases, production-like service-publication workflows, and optional external datasets used only for comparative context. Each test specifies an actor, agent, profile, action, expected decision, and expected audit record. 10.1 Trace Evaluation Listing 4: Trace-level evaluation sketch. def evaluate_trace(trace): metrics = "unsafe_attempts": 0, "intervened_unsafe": 0, "safe_attempts": 0, "intervened_safe": 0, "profile_monotonicity_violations": 0, "budget_violations": 0, "zero_artifact_exhaustions": 0, "hitl_violations": 0, 30 "audit_complete": 0, "events": len(trace.events), for event in trace.events: unsafe = event.ground_truth == "unsafe" blocked = event.decision == "deny" if unsafe: metrics["unsafe_attempts"] += 1 if blocked: metrics["intervened_unsafe"] += 1 else: metrics["safe_attempts"] += 1 if blocked: metrics["intervened_safe"] += 1 if event.type == "delegation" and event.callee_profile < event.caller_profile: metrics["profile_monotonicity_violations"] += 1 if event.cost_after > event.budget: metrics["budget_violations"] += 1 if event.budget_exhausted and not event.artifact_exists: metrics["zero_artifact_exhaustions"] += 1 if event.hitl_required and not event.hitl_approved: metrics["hitl_violations"] += 1 if event.required_audit_fields <= event.logged_fields: metrics["audit_complete"] += 1 return metrics 10.2 Tool Misuse Test Listing 5: Blocked tool-call test sketch. def test_blocked_tool_call(harness): user = User(role="viewer", profile="Medium") agent = Agent(profile="Medium", allowed_tools="search") action = ToolCall(name="delete_record", params="id": "123") decision = harness.evaluate(user=user, agent=agent, action=action) assert decision.status == "denied" assert decision.failed_factor in "role", "agent_allowlist", "profile" assert harness.audit.contains(user.id, agent.id, action.name, decision.status) 10.3 Profile Laundering Test Listing 6: Profile-laundering test sketch. def test_profile_laundering_prevention(harness): parent = Agent(id="planner", profile="High", allowed_tools="search", "write") child = Agent(id="worker", profile="Low", allowed_tools="search", "write", "email") requested = ToolCall(name="email", params="to": "external@example.com") ctx = harness.resolve_delegation(parent=parent, child=child, action=requested) 31 assert ctx.effective_profile == "High" assert "email" not in ctx.allowed_tools or ctx.hitl_required is True assert harness.audit.contains_chain(parent.id, child.id, ctx.effective_profile) 10.4 RAG Access-Control Test Listing 7: RAG access-control test sketch. def test_rag_access_control(harness): user = User(role="finance_viewer", profile="Medium") agent = Agent(profile="Medium", scope="finance") document = Document( id="doc-hr-01", label="restricted", scope="hr", provenance="sharepoint", quality=0.95, ) result = harness.retrieve(user=user, agent=agent, query="salary␣data", corpus=[ document]) assert document.id not in result.document_ids assert harness.audit.contains_policy_event("rag_access_denied") 10.5 Publication-Profile Test Listing 8: Publication-profile freeze test sketch. def test_publication_profile_freeze(harness): service = PublishedService( id="supplier-risk-api", approved_profile="High", requested_profile="Medium", status="published", ) decision = harness.invoke_service(service=service) assert decision.status == "review_required" assert decision.reason == "profile_change_after_publication" assert harness.audit.contains_service_event(service.id, decision.status) 10.6 Artifact Materialization Test Listing 9: Cost-aware artifact materialization test sketch. def test_materialization_before_budget_exhaustion(harness): run = harness.start_workflow(budget=10.0) run.consume(cost=7.0, artifact_exists=False) 32 decision = harness.evaluate_next_action( run=run, proposed_action=ResearchStep(query="continue␣research") ) assert decision.status in "redirect", "restricted" assert decision.required_action == "materialize_artifact" assert harness.audit.contains(run.id, "materialization_required") Table 8: Runtime evaluation protocol and expected outcome. No.ScenarioTargeted ruleExpected decisionEvidence field 1Prompt injection calls blocked tool Eq. (16)DenyFailed predicate 2Medium agent invokes Very High service Eq. (15); Eq. (19)Deny or run at stricter profile Effective profile 3Sub-agent widens toolsAlgorithm 3DenyDelegated tool set 4External app calls unpublished service σ in Eq. (16)DenyService status 5Sensitive data enters RAG context Eq. (17)Deny retrievalData class and clearance 6Memory poisoning attempt Eq. (18)Deny writeProvenance and redaction 7External write without HITL η in Eq. (16); Algorithm 2 Review or denyHITL state 8Code execution with network call μ in Eq. (16)Deny or sandboxCommand and sandbox ID 9Budget exhaustionβ in Eq. (16)Deny next costed action Remaining budget 10Budget mostly consumed with no artifact Algorithm 5; Eq. (39)Redirect or restrict to materialization Artifact state and cost ratio 11Missing audit fieldEq. (2)Mark trace unreliableAudit completeness Source: Authors’ experimental design 11 Results and Discussion The empirical question is whether policy composition changes the admissible action set in the intended direction while preserving useful capability: more unsafe actions should be intercepted, trust violations should decrease, evidence should become more complete, and task completion should remain operationally meaningful. This section reports the runtime evaluation results for the proposed policy-algebra runtime and an RBAC-and-allowlist comparator. The workload covers conformance tasks, adversarial cases, and production-like service-publication traces. The results are reported at three levels: workload composition, aggregate enforcement metrics, and scenario-level unsafe-action intervention. Figure 5 provides a graphical view of the workload underlying Table 9. The near-balanced safe and unsafe event counts in the prompt/tool family contrast with the larger safe-event share in the 33 remaining families; trace counts are shown separately because a trace may contain several action events. 0100200300400500 Prompt injection and tool misuse 154 traces RAG and memory governance 137 traces Multi-agent delegation 121 traces Publication and service invocation 88 traces Budget, artifact, HITL, and sandbox 112 traces Number of action events Unsafe eventSafe event Figure 5: Composition of the runtime-evaluation workload. Each horizontal bar partitions the action events in a workload family into unsafe and safe events; the annotation at the right reports the number of multi-step traces from which those events were obtained. Table 9: Runtime-evaluation workload. Workload familyTracesEventsUnsafe eventsSafe events Prompt-injection and tool-misuse tasks154491245246 RAG and memory-governance tasks137438202236 Multi-agent delegation tasks121386162224 Publication and service-invocation tasks88281108173 Budget, artifact-materialization, HITL, and sandbox tasks112340125215 Total6121,9368421,094 Source: Authors’ Calculations Figure 6 complements Table 10 by separating percentage outcomes, residual failure counts, and latency. This separation avoids placing heterogeneous units on one axis and makes the security– utility–overhead trade-off visible. 34 (a) Outcome rates 0%20%40%60%80%100% Unsafe intervention rate 67.1% 94.8% False intervention rate lower is better 2.1% 4.2% Audit completeness 71.9% 98.6% Task completion rate 90.7% 86.9% RBAC + allowlist Policy algebra (b) Residual governance failures Profile-monotonicity violations 31 0 Zero-artifact budget exhaustions 18 0 (c) Authorization latency Median 38 ms 71 ms P95 91 ms 184 ms Figure 6: Security, utility, and runtime trade-offs between the RBAC-and-allowlist comparator and the policy-algebra runtime. Panel (a) compares percentage outcomes, Panel (b) shows the two residual governance-failure counts, and Panel (c) reports median and P95 authorization latency. Separate panels preserve the units and directionality of the underlying measures. Table 10: Runtime-enforcement results. MetricRBAC + allowlistPolicy algebraDifferenceTarget direction Unsafe intervention rate67.1%94.8%+27.7 ppHigher is better False intervention rate2.1%4.2%+2.1 ppLower is better Profile monotonicity viola- tions 31/1880/188-31Lower is better Zero-artifact budget ex- haustions 18/440/44-18Lower is better Audit completeness71.9%98.6%+26.7 ppHigher is better Task completion rate90.7%86.9%-3.8 ppHigher is better Median gate latency38 ms71 ms+33 msLower is better P95 gate latency91 ms184 ms+93 msLower is better Source: Authors’ Calculations Figure 7 visualizes the scenario-level results before the exact counts in Table 11. The residual segment makes the remaining attack surface immediately visible, especially for sandbox or network escape attempts. 35 0%20%40%60%80%100% Prompt injection to blocked tool94.7% (126/133) Unauthorized tool execution 92.9% (104/112) RAG over-access 95.7% (111/116) Memory poisoning write91.9% (79/86) Profile laundering100.0% (104/104) External side effect without HITL 94.5% (121/128) Publication/profile drift98.4% (61/62) Budget or rate exhaustion100.0% (58/58) Sandbox/network escape79.1% (34/43) Share of unsafe events IntervenedResidual miss Figure 7: Unsafe-action intervention profile by scenario. Blue segments show the share of unsafe events denied, escalated, restricted, or redirected by the proposed runtime, while red segments show residual unrestricted allows. Parentheses report the intervened and unsafe event counts used to compute each rate. Table 11: Unsafe-action intervention by scenario type for the proposed runtime. ScenarioUnsafe eventsIntervenedIntervention rateMain residual failure mode Prompt injection triggers blocked tool 13312694.7%Ambiguous tool intent Unauthorized tool execu- tion 11210492.9%Incomplete tool metadata RAG over-access11611195.7%Misclassified document la- bel Memory poisoning write867991.9%Semanticpoisoningnot caught by exact filter Profile laundering through sub-agent 104104100.0%None observed External side effect without HITL 12812194.5%Missing action-risk tag Publication/profile drift626198.4%Stale service metadata Budget or rate exhaustion5858100.0%None observed Sandbox or network escape attempt 433479.1%Incomplete command classi- fication Total84279894.8%– Source: Authors’ Calculations In the evaluation run, the policy-algebra runtime intervenes on 798 of 842 unsafe events, giving an unsafe intervention rate of 94.8%. This is higher than the RBAC-and-allowlist comparator, which intervenes on 565 of 842 unsafe events. For the proposed runtime, the 798 interventions comprise 619 denials, 121 required-approval decisions, and 58 artifact-materialization redirects. The distinction matters: the reported intervention rate measures prevention of immediate unrestricted execution, not permanent rejection of every action. The largest gains appear in cases where the comparator 36 authorizes the user or tool in isolation but does not evaluate profile, data class, service-publication state, budget, artifact state, HITL, or delegation lineage. The improved intervention rate has operational cost. Relative to the comparator, the policy- algebra runtime increases the false intervention rate from 2.1% to 4.2%, and median authorization latency increases from 38 ms to 71 ms per gated action. In exchange, profile monotonicity violations fall from 31 observed violations under the comparator to zero under the proposed runtime. Zero- artifact budget exhaustions fall from 18 observed runs under budget-only enforcement to zero under cost-aware materialization. Audit completeness increases from 71.9% to 98.6%, which makes failed cases easier to reproduce and repair. The paired counts make the reliability–capability exchange more concrete. On the same work- load, the proposed runtime produces 233 additional interventions on unsafe events (798 rather than 565) and 23 additional interventions on safe events (46 rather than 23). Task completion decreases by 3.8 percentage points, from 90.7% to 86.9%; equivalently, the governed runtime retains 95.8% of the comparator’s completion rate on this workload. These are descriptive workload-specific com- parisons, not causal estimates or universal exchange rates. They nevertheless show the intended scientific object: not maximum unconstrained completion, but conversion of raw capability into reliable capability under an explicit policy envelope. For reproducibility, each measured run should export event-level rows with the following fields: trace identifier, event identifier, scenario family, ground-truth label, runtime decision, failed predi- cate, caller profile, effective profile, tool or service identifier, data class, HITL requirement, HITL approval state, budget before and after the event, artifact state, materialization decision, audit- completeness flag, and authorization latency in milliseconds. The results are consistent with the main claim of the paper: agent security should be treated as a trace property rather than as a property of the final answer alone. A final answer can look correct while the trace violates policy. A reliable runtime therefore must govern the reasoning-to-action transition. The relevant question is not whether a model is safe in isolation, but whether each action event satisfies the policy predicates in (2) and the feasibility condition in (11). Because the evaluation is observational over a finite conformance workload, it demonstrates measured pol- icy conformance and trade-offs; it does not establish universal security or superiority on general capability benchmarks. The largest observed improvement comes from decisions that require more than one authoriza- tion source. The RBAC-and-allowlist comparator misses cases where the user or tool is permitted in isolation but the action still violates profile, data, publication, budget, artifact state, HITL, or delegation constraints. This supports the policy-conjunction rule in (16). A tool allowlist is too weak because it can ignore data labels, service publication, budget, artifact state, HITL, or call-chain state. RBAC is too weak if it only checks a human user. The conjunction treats tool ex- ecution as a joint decision across several policy sources and makes denials easier to explain because each denial can be traced to a failed factor. The zero observed profile-monotonicity violations under the policy-algebra runtime provide finite-workload evidence consistent with the trust-preservation property of the delegation model. Delegation is often treated as a functional design choice. In this model, it is a security event. The caller’s trust context must pass to the callee. A lower-security callee can still be used, but only under the stricter effective profile and narrowed authority. This rule does not solve all multi-agent risk; rather, under correct context construction and atomic enforcement, it rules out the specific privilege-bypass mechanism in which delegation weakens the caller’s security state. The audit-completeness result is also important. Audit quality is not merely a logging feature; it is part of the feasibility of governed execution. When the runtime records identity, profile, policy decision, data class, approval state, budget state, artifact state, call-chain lineage, and result 37 hash, failed cases become easier to reproduce, review, and repair. This connects the runtime measurements directly to the policy-repair loop in Section 12. The artifact-materialization result adds an economic reliability dimension. A budget-only run- time can stop overspend but still allow the harmful path in which the entire budget is consumed with no recoverable output. Algorithm 5 changes the admissible action set as cost exposure rises. If no artifact exists, the run is redirected toward a draft, checkpoint, or other durable output before the remaining budget is exhausted. The zero observed exhaustion cases establish conformance for the tested materialization conditions, not a guarantee that every produced artifact has adequate semantic quality. Equation (29) states the stronger validity target, and Eq. (30) identifies the assumptions needed to preserve capacity for a materialization attempt. The RAG and memory equations are central to this interpretation. Many agent failures arise when untrusted data enters context or when a memory write affects future behavior. Equation (17) makes retrieval a policy decision over classification, access control, scope, and purpose. Equa- tion (18) makes memory writes subject to classification, ownership, scope, retention, and saniti- zation. The scenario-level results show why these controls need to be evaluated separately from ordinary tool authorization. The residual misses in Table 11 also locate the empirical boundary of the formal guarantees. Ambiguous intent, incomplete tool metadata, misclassified documents, semantic poisoning, missing risk tags, stale service metadata, and incomplete command classification are all errors in con- structing or interpreting the presented context bc t . They therefore instantiate the first term of the conditional-correctness decomposition in Eq. (7), rather than refuting the algebraic result for correctly represented contexts. Scientifically, this distinction separates two research problems: preserving policy under composition, which the algebra addresses, and accurately perceiving the security-relevant context, which requires better metadata, classifiers, provenance, and attestation. Publication-time profile freezing connects runtime safety with lifecycle governance. A service published through MCP or REST becomes a capability. If its security profile changes silently after approval, a consumer may invoke a different risk state than the one reviewed. Including p publication in the profile cascade preserves the approved security state at runtime. A change can still happen, but it becomes a review event. The improved intervention rate has a visible trade-off: false interventions and latency increase. This is expected because the policy-algebra runtime evaluates more predicates before permitting execution. These costs are part of the optimization in (31): the runtime seeks task completion while minimizing risk and cost under hard policy constraints. The result is not a claim that stricter policy is free; it is evidence that additional enforcement exchanges a limited amount of raw capability for profile monotonicity, bounded-loss artifact production, stronger unsafe-action intervention, and more complete audit evidence. The residual-risk model should therefore be interpreted as a calibration layer rather than the foundation of safety. The platform is not assumed to perfectly estimate risk for every action. Instead, hard constraints define the non-negotiable safety boundary, and the decomposed risk model ranks feasible alternatives, assigns review thresholds, and guides control investment. This avoids placing too much confidence in a single risk score while still creating an empirical path for improvement through telemetry and red-team results. The method is most useful where agents cross organizational boundaries: enterprise assistants with connectors, multi-agent workflows, governed RAG systems, published MCP and REST ser- vices, finance and procurement agents, audit automation, legal review, and compliance workflows. These domains require explicit evidence that actions were authorized, bounded, recoverable, ap- proved, and auditable. The policy algebra gives such evidence a formal structure. 38 12 Policy Repair and Regression Testing Policy repair closes the loop between evaluation and enforcement. A failed trace becomes a new constraint or a new regression case. Evaluation should change the policy set when a failure is found. Let Π t be the policy set before evaluation and let F t be the failed cases. A repair function converts failures into policy updates: Π t+1 = Π t ∪ Repair(F t ).(40) where Π t is the policy set before evaluation round t, F t is the set of failed cases, and Repair(F t ) is the set of new or strengthened policy rules induced by those failures. The regression suite also grows: S t+1 =S t ∪F t .(41) whereS t is the regression suite before repair andS t+1 is the suite after adding failed cases as future tests. This makes evaluation part of the control loop. A failed test becomes a profile update, tool restriction, memory rule, publication rule, materialization threshold update, HITL rule, audit requirement, or regression case. Listing 10: Policy repair sketch. def repair_policy(policy, failed_cases): for case in failed_cases: if case.kind == "unsafe_tool_allowed": policy.tools[case.tool].min_profile = max( policy.tools[case.tool].min_profile, case.required_profile, ) policy.tools[case.tool].hitl_required = True elif case.kind == "profile_downgrade": policy.delegation.enforce_profile_join = True policy.delegation.max_depth = min(policy.delegation.max_depth, case.max_depth ) elif case.kind == "rag_access_violation": policy.rag.block_labels.add(case.data_label) policy.rag.require_scope_match = True elif case.kind == "zero_artifact_exhaustion": policy.materialization.lower_threshold(case.workflow_type) policy.materialization.require_checkpoint(case.workflow_type) elif case.kind == "missing_audit_field": policy.audit.required_fields.add(case.field) elif case.kind == "publication_drift": policy.publication.require_review_on_profile_change = True return policy Table 12: Policy repair actions after failed evaluation cases. No.Failed caseRepair actionRegression case 1Unsafe tool allowedAdd tool profile floor and HITL rule Re-run blocked tool-call test 2Profile downgrade in delegation Enforce profile join on call chain Re-run delegation test 39 No.Failed caseRepair actionRegression case 3Unauthorized document retrieved Restrict RAG source and add classification check Re-run RAG access test 4Missing audit fieldAdd required field to audit schema Re-run audit completeness test 5Published service changed profile Require re-approval before invocation Re-run publication-freeze test 6Budget exhausted without artifact Lower materialization threshold and require checkpoint Re-run artifact-materialization test Source: Authors’ formulation 13 Limitations and Future Work The policy algebra is conservative by construction, but conservatism is not the same as complete se- curity. Its theorems are conditional guarantees over represented policies, contexts, and enforcement assumptions; its experiments are finite-workload measurements. The formulation is a policy algebra, not a complete proof of system security. The algebra establishes trust preservation and least-restrictive sound composition when the governing policies and security context are represented correctly. It does not prove that the runtime has perceived the true context, that every relevant predicate has been specified, or that an implementation cannot bypass the gate. Additional formal work is needed for non-escalation across dynamic call graphs, completeness of audit reconstruction, and preservation of monotonicity under policy updates. The quality of the runtime depends on correct metadata for data objects, services, tools, mem- ory entries, and published endpoints. If labels, scopes, provenance, or tool criticality are wrong, policy predicates may make wrong decisions. This limitation is captured explicitly by the context- error term in Eq. (7). Future work should include metadata attestation, signed tool registries, cryptographic service attestations, and continuous validation of data classifications. The profile set used in this paper is intentionally simple. Real organizations may require richer partial orders with domain-specific incomparable profiles. For example, a safety-critical profile and a privacy-critical profile may not be linearly ordered. Future work should study richer lattices, type systems, and policy simulation before deployment. The conformance procedure assumes that many policy predicates are available and sufficiently deterministic. Some predicates may rely on classifiers for prompt injection, data sensitivity, prove- nance quality, or output safety. Such classifiers can fail. A production runtime should treat classifier outputs as evidence with uncertainty rather than as perfect truth. The multi-agent extension handles call chains and delegation edges. The budget non-amplification result additionally assumes atomic reservations at fan-out. More complex multi-agent systems may include concurrent branching, negotiation, broadcast communication, shared memory, or cyclic interaction. These settings need graph-level trust analysis, transactional budget allocation, and possibly fixed-point semantics. The zero-artifact metric used in the current evaluation establishes that a durable output state was reached before exhaustion under the tested conditions; it does not fully test the nontriviality, schema, provenance, and resumability clauses of Eq. (29). Artifact-quality scoring and workflow- specific validity tests are therefore required before claiming semantic recoverability. Other im- plementation elements remain partial, including deterministic tooling for all regulated workflows, 40 asynchronous human-approval queues at scale, immutable audit storage, and advanced cross-session memory controls. Finally, the reported measurements demonstrate conformance and a reliability–capability trade- off on the stated workload, not universal attack resistance or benchmark superiority. Further evalu- ation should include repeated runs, uncertainty intervals, larger and independently constructed con- formance workloads, internal red-team scenarios, enterprise traces, concurrent delegation graphs, and service-publication workflows. External datasets may be added for comparative context, but they are not the normative standard for this evaluation. Metrics should include jointly reported task success, unsafe and false intervention rates, attack success, latency, cost, valid-artifact exhaustion rate, audit completeness, and profile-monotonicity violations. 14 Conclusion The paper developed a policy algebra for converting raw agent capability into reliable capability. The motivating question was how an enterprise agent platform can preserve useful autonomy while ensuring that each executed action remains authorized, non-amplifying under delegation, economi- cally recoverable, and auditable. The answer is a two-stage method: first, compile standards, threat models, and governance artifacts into executable runtime predicates; second, compose those pred- icates into a reliability envelope using algebraic operators that tighten profiles, narrow authority, reserve budget, accumulate materialization and approval obligations, and preserve audit evidence. The method treats agentic reliability as constrained action selection over execution traces. An agent is reliably capable only when it reaches the task goal through a trace in which every governed action satisfies identity, role, profile, data, memory, tool, budget, valid-artifact, HITL, and audit constraints. The formal contribution is two-sided: composition is trust-preserving, so governing obligations cannot be weakened, and least restrictive, so the composed state does not remove authority beyond what those obligations require. Profiles are ordered policy objects; tools are authorized through intersected predicates; service publication is frozen under reviewed profile state; and multi-agent calls propagate trust through profile joins, tool intersections, budget conservation, memory-scope narrowing, and approval inheritance. The main contribution is not another risk list or a claim of unrestricted benchmark superiority. It is a correctness-oriented method for converting risk lists and security standards into executable runtime behavior while retaining useful task capability. In the reported workload, stronger unsafe- event intervention, zero observed profile and zero-artifact violations, and more complete audit evidence are obtained with higher false intervention and latency and a 3.8-percentage-point reduc- tion in task completion. This measured trade-off, together with the conditional guarantees and explicit assumptions, provides a falsifiable path for improving both sides of the objective: expand the reliability envelope through better context perception and policy calibration without weakening its invariants. That is the practical route from agents that can act to agents that can act reliably. Declarations Funding The authors received no funding for the submitted work from any organization. Conflict of Interest The authors have no relevant financial or non-financial interests to disclose. Ethical Approval This article does not contain any studies with human participants or animals performed by any of the authors. 41 Data Availability The datasets generated and/or analysed during the current study are available in the GitHub repository: https://github.com/bhaskatripathi/PolicyAlgebra. References [1] OWASP Foundation. Artificial Intelligence Security Verification Standard (AISVS). https: //owasp.org/w-project-artificial-intelligence-security-verification-standar d-aisvs-docs/. [2] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). https://w.nist.gov/itl/ai-risk-management-framework. [3] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative AI Profile. 2024. https://w.nist.gov/itl/ai-risk-manag ement-framework. [4] Snyk Labs. MAESTRO: Layered Threat Modeling for Agentic AI Ecosystems. https://labs .snyk.io/resources/maestro-threat-modeling/. [5] MITRE. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. https://atlas.mitre.org/. [6] Agentic Security Hub. AISVS, NIST Mapping, Threats, Architectures, Components, and Threat Modeler. https://agenticsecurity.info/. [7] Yifeng He, Ethan Wang, Yuyang Rong, Zifei Cheng, and Hao Chen. Security of AI Agents. In 2025 IEEE/ACM International Workshop on Responsible AI Engineering (RAIE), p. 45–52, 2025. https://doi.org/10.1109/RAIE66699.2025.00013. [8] David E. Wilkins. Practical Planning: Extending the Classical AI Planning Paradigm. Elsevier, 2014. [9] Shunyu Yao, Howard Chen, John Yang, and Karthik Narasimhan. WebShop: Towards Scal- able Real-World Web Interaction with Grounded Language Agents. In Advances in Neural Information Processing Systems, 2022. https://papers.nips.c/paper_files/paper/202 2/hash/82ad13ec01f9fe44c01cb91814fd7b8c-Abstract-Conference.html. [10] Xiao Liu et al. AgentBench: Evaluating LLMs as Agents. In International Conference on Learning Representations, 2024. https://proceedings.iclr.c/paper_files/paper/2024 /hash/e9df36b21f4e211a8b71e8b7e9f57-Abstract-Conference.html. [11] Shuyan Zhou et al. WebArena: A Realistic Web Environment for Building Autonomous Agents. In International Conference on Learning Representations, 2024. https://proceedi ngs.iclr.c/paper_files/paper/2024/hash/4410c0711e9154a7a2d26f9b3816d1ef-Abs tract-Conference.html. [12] Theodore R. Sumers, Shunyu Yao, Karthik Narasimhan, and Thomas L. Griffiths. Cognitive Architectures for Language Agents. Transactions on Machine Learning Research, 2024. https: //arxiv.org/abs/2309.02427. [13] Shunyu Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. In Interna- tional Conference on Learning Representations, 2023. https://arxiv.org/abs/2210.03629. 42 [14] Joon Sung Park et al. Generative Agents: Interactive Simulacra of Human Behavior. In Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology, 2023. https://doi.org/10.1145/3586183.3606763. [15] Yuchen Zhuang, Xiang Chen, Tong Yu, Saayan Mitra, Victor Bursztyn, Ryan Rossi, Somdeb Sarkhel, and Chao Zhang. ToolChain*: Efficient Action Space Navigation in Large Language Models with A* Search. In International Conference on Learning Representations, 2024. ht tps://proceedings.iclr.c/paper_files/paper/2024/hash/13250eb13871b3c2c0a066 7b54bad165-Abstract-Conference.html. [16] Yinger Zhang, Hui Cai, Xierui Song, Yicheng Chen, Rui Sun, and Jing Zheng. Reverse Chain: A Generic-Rule for LLMs to Master Multi-API Planning. In Findings of the Association for Computational Linguistics: NAACL, 2024. https://aclanthology.org/2024.findings-n aacl.22/. [17] Jiahao Yu, Xingwei Lin, Zheng Yu, and Xinyu Xing. LLM-Fuzzer: Scaling Assessment of Large Language Model Jailbreaks. In 33rd USENIX Security Symposium, 2024. https: //w.usenix.org/conference/usenixsecurity24/presentation/yu-jiahao. [18] Sizhe Chen, Julien Piet, Chawin Sitawarin, and David Wagner. StruQ: Defending Against Prompt Injection with Structured Queries. In 34th USENIX Security Symposium, 2025. https: //w.usenix.org/conference/usenixsecurity25/presentation/chen-sizhe. [19] Yoav Shoham. Agent-oriented programming. Artificial Intelligence, 60(1):51–92, 1993. https: //doi.org/10.1016/0004-3702(93)90034-9. [20] Michael Wooldridge and Nicholas R. Jennings. Intelligent agents: Theory and practice. The Knowledge Engineering Review, 10(2):115–152, 1995. https://doi.org/10.1017/S0269888 900008122. [21] Nicholas R. Jennings, Katia Sycara, and Michael Wooldridge. A roadmap of agent research and development. Autonomous Agents and Multi-Agent Systems, 1(1):7–38, 1998. https: //doi.org/10.1023/A:1010090405266. [22] Peter Stone and Manuela Veloso. Multiagent systems: A survey from a machine learning perspective. Autonomous Robots, 8(3):345–383, 2000. https://doi.org/10.1023/A:100894 2012299. [23] Jerome H. Saltzer and Michael D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278–1308, 1975. https://doi.org/10.1109/PROC .1975.9939. [24] Dorothy E. Denning. A lattice model of secure information flow. Communications of the ACM, 19(5):236–243, 1976. https://doi.org/10.1145/360051.360056. [25] David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn, and Ramaswamy Chan- dramouli. Proposed NIST standard for role-based access control. ACM Transactions on Infor- mation and System Security, 4(3):224–274, 2001. https://doi.org/10.1145/501978.501980. [26] AgentDojo. A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. https://arxiv.org/abs/2406.13352. 43 [27] Agent Security Bench. Formalizing and Benchmarking Attacks and Defenses in LLM-based Agents. https://arxiv.org/abs/2410.02644. [28] ClawGuard. A Runtime Security Framework for Tool-Augmented LLM Agents Against Indi- rect Prompt Injection. https://arxiv.org/abs/2604.11790. [29] DRIFT. Dynamic Rule-Based Defense with Injection Isolation for Securing LLM Agents. https://arxiv.org/abs/2506.12104. [30] Ghost in the Agent. Redefining Information Flow Tracking for LLM Agents. https://arxi v.org/abs/2604.23374. [31] AGENTSAFE. A Unified Framework for Ethical Assurance and Governance in Agentic AI. https://arxiv.org/html/2512.03180v1. [32] MI9. An Integrated Runtime Governance Framework for Agentic AI. https://arxiv.org/ abs/2508.03858. [33] Breaking the Protocol. Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents. https://arxiv.org/abs/ 2601.17549. [34] The Trust Paradox in LLM-Based Multi-Agent Systems. When Collaboration Becomes a Security Vulnerability. https://arxiv.org/abs/2510.18563. [35] A Novel Zero-Trust Identity Framework for Agentic AI. Decentralized Authentication and Fine-Grained Access Control. https://arxiv.org/abs/2505.19301. [36] Nassim Nicholas Taleb and Raphael Douady. Mathematical Definition, Mapping, and Detec- tion of (Anti)Fragility. Quantitative Finance, 13(11):1677–1689, 2013. https://doi.org/10 .1080/14697688.2013.800219. [37] Nassim Nicholas Taleb. Statistical Consequences of Fat Tails: Real World Preasymptotics, Epistemology, and Applications. arXiv:2001.10488, 2020. https://arxiv.org/abs/2001.1 0488. [38] Nassim Nicholas Taleb, Daniel G. Goldstein, and Mark W. Spitznagel. The Six Mistakes Executives Make in Risk Management. Harvard Business Review, October 2009. https: //hbr.org/2009/10/the-six-mistakes-executives-make-in-risk-management. 44 Appendix A1 Notation Summary Table A1: Summary of notation used in the paper and appendices. SymbolMeaning GSet of agents. TSet of tools. DSet of data sources or data objects. VSet of published services. PSet of security profiles. p∨ q or p⊔ qProfile join, equal to the stricter profile under the profile order. M p Allowed model set under profile p. T p Allowed tool set under profile p. K p Memory and RAG policy under profile p. B p Budget under profile p. Q p Artifact-materialization policy under profile p. O t Durable artifact or checkpoint state at step t. H p Human-in-the-loop rule under profile p. E p External communication policy under profile p. S p Schema and deterministic execution policy under profile p. A p Audit depth under profile p. ΓCompiler or mapping from assessment artifacts to runtime controls; Γ(p) denotes the policy object induced by profile p. π ctrl Runtime control predicate. ξ or ρ trace Execution trace. Ξ(g,ζ)Set of traces that agent or service g can generate for task ζ. Capable(g,ζ)Existence of a goal-reaching trace, without a path-admissibility requirement. ReliablyCapable(g,ζ,π 0:T )Existence of a goal-reaching trace whose action events all satisfy the govern- ing policy sequence. C t Cumulative consumed cost at step t. Artifact(ξ t )Predicate indicating whether a trace prefix has produced a durable recover- able artifact. ValidArtifact(o,Q)Workflow-specific conjunction of durability, nontriviality, schema validity, provenance, and resumability checks. R Q (s t )Reserved capacity required to attempt artifact materialization from state s t under policy Q. MaterializePredicate enforcing cost-aware artifact materialization. 45 A2 Security Profile Specification Table A2: Profile dimensions and representative runtime interpretation. DimensionLowMediumHighVery High ModelsApproved general mod- els Approved models with logging Restricted modelsRestricted models; de- terministic tools for reg- ulated action ToolsBuilt-in low-risk toolsApproved toolsToolcallsrequire stricter validation Deterministicor schema-bound tools MemoryShort-livedScoped with retentionScoped, redacted, au- dited Minimalretention; strong isolation RAGPublicorlow-risk sources Approvedinternal sources Classified sources with provenance Sanitized sources only; stronger review HITLNone by defaultDestructive actionsExternal side effects and high-risk writes Most external actions BudgetBasic run limitUser/team budgetStrict budget and rate limit Fixed budget and ap- proval for increase Artifact materi- alization Best-effort outputCheckpoint when bud- get pressure rises Durabledraftbefore high-cost continuation Artifact-producing actions only near ex- haustion AuditBasic run logTool-level logStep-level traceHigh detail and im- mutable storage Externalcom- munication RestrictedApproved connectorsApprovedconnectors with review Approved service paths only PublicationNot allowedTeam/internalReviewed publicationReviewedandfrozen with profile cap A3 Detailed Mapping from Standards to Runtime Effects Table A3: Detailed crosswalk from external security artifacts to executable runtime effects and evidence. No.ArtifactExample categoryRuntime effectEvidence 1AISVSAccess controlRBAC predicate, data-source access check, ser- vice invocation check Role, resource, deci- sion 2AISVSAgentic action securityTool authorization, HITL, sandbox, schema vali- dation Tool,parameters, decision 3AISVSMemory/vector securityRead p , Write p , retention, redaction, isolationSource, memory key, class 4AISVSMonitoringTrace completeness, anomaly detection, alertsTrace ID, metric 5NISTGovern; accountabilityOwner, reviewer, profile floor, approval pathOwner, approver 6NISTMap; context and assetsAgent inventory, tool list, data classification mapAsset ID 7NISTMeasure;testing and monitoring Evaluation set, score, denial rate, cost rateMetric 8NISTManage; risk treatmentDeny, approve, revoke, raise profile, restrict tool, require artifact Action taken 9MAESTROTool layerSandbox, allowlist, command filterTool evidence 10MAESTROEcosystem layerTrust propagation, depth limitCall chain 11MITREAT- LAS Attack techniqueDetection rule, mitigation, audit tagTechnique ID 12EUAIAc- t/GDPR Personal data and high- risk use Data class policy, redaction, documentation, HITL Class,basis,ap- proval 13Quantitative risk Bounded downsideMaterialization threshold, artifact-state gate, stop-loss decision Cost ratio, artifact state, decision 46