PaperlayerView exact revision on arXiv

Source-linked AI summary

A Policy Algebra for Trust-Preserving Agentic AI Execution

Bhaskar Tripathi, Anurag Kumar, Ramendra Kumar, Bhavesh Gadhe

arXiv:2608.16402v1cs.AI

TL;DR

Agentic systems connect language-model reasoning to actions, while enterprise execution imposes reliability and security requirements beyond task completion. This paper defines a policy algebra for admissible execution; its evaluation reports a 94.8% unsafe intervention rate, 86.9% task-completion rate, zero observed profile-monotonicity and zero-artifact budget-exhaustion violations, and 98.6% audit completeness.

  • Problem

    Agentic systems connect language-model reasoning to actions, while enterprise execution imposes reliability and security requirements beyond task completion.

    Source: §1 · p. 2

  • Method

    It defines a policy algebra in which profiles are ordered, delegation joins rather than overwrites, tool authorization conjuncts policy checks, and budget pressure triggers recoverable artifact obligations.

    Source: §1 · p. 4, §5.9 · p. 20

  • Results

    94.8% unsafe intervention rate and 86.9% task-completion rate were reported, alongside zero observed profile-monotonicity and zero-artifact budget-exhaustion violations and 98.6% audit completeness.

    Source: §11 · pp. 36–37

  • Takeaways & Limitations

    For cross-organizational agent workflows, the algebra gives formal structure to evidence that actions were authorized, bounded, recoverable, approved, and auditable.

    Source: §11 · p. 38

    The algebra is not a complete system-security proof: its guarantees assume correctly represented policies and context, and experiments are finite-workload measurements.

    Source: §13 · p. 40

Abstract

from arXiv · show

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.

1 Introduction · 2 Background and Related Work

The section frames agent reliability as a property of the full action path and motivates executable policy composition to constrain actions while preserving useful autonomy. It situates this need in prior agent-security work, MCP governance, multi-agent trust, and quantitative risk, and presents cost-aware artifact materialization as a contribution to bounded-loss execution.

1 Introduction

  • Reliable capability requires every action in a selected execution path to remain admissible, shifting the objective from goal completion alone to useful autonomy within a reliability envelope.The protected transition turns a model proposal into an action under identity, profile, data, memory, budget, artifact, approval, and audit constraints.Source: §1 · pp. 2, 4, Figure 1 · p. 5
  • The policy algebra composes enterprise profiles, access controls, tools, memory, publication, budgets, approvals, and evidence into the least restrictive state satisfying all governing inputs.It uses a policy cascade and conjunctive authorization predicates; delegation joins profiles and narrows tools, budget, and memory, while cost-aware materialization and audit evidence support recoverable execution.Source: §1 · pp. 3–5

2.1 Agentic AI and Multi-Agent Systems

  • Agentic systems turn model outputs into state-changing operations through tool use, data retrieval, memory updates, and delegation, making governed action—not content filtering alone—the security target.Multi-agent delegation can widen authority without explicit propagation rules; the paper addresses this with monotone profile joins and narrowing of tools, budget, and memory.Source: §2.1 · p. 6

2.2 Standards, Threat Models, and Aggregators

  • AISVS, NIST AI RMF, MAESTRO, and AgenticSecurity.info provide complementary control and risk knowledge, but runtime policy composition remains necessary.The paper treats these artifacts as a knowledge substrate from which controls can be translated into executable decisions.Source: §1 · p. 2, §2.2 · p. 6

2.3 Runtime Defenses, Testbeds, and Governance

  • Agent-security testbeds, runtime defenses, information-flow work, and governance frameworks supply useful cases and controls, but do not define the enterprise policy state.The paper evaluates against its policy algebra, control taxonomy, and conformance protocol rather than any single public testbed.Source: §1 · p. 3, §2.3 · p. 6

2.4 Agentic Identity and Access Management

  • Agentic IAM work addresses authentication and base authorization, while this paper focuses on narrowing execution authority after identity is established.Post-authentication constraints include tools, memory, publication, budget, artifact production, approvals, and delegation.Source: §2.4 · pp. 6–7

2.5 Cost-Aware Execution and Bounded-Loss Design

  • When an unattended run consumes budget without producing a durable artifact, it fails as governed execution even if it respects a spending cap.As cost exposure becomes material and no artifact exists, the runtime constrains admissible actions toward producing a draft, checkpoint, file, record, or partial result.Source: §2.5 · p. 7
  • The related-work framing covers collaboration exposure [34], monotonic trust and call-chain constraints, and quantitative downside and fat-tail risk [37] [36].It also notes payoff behavior under uncertainty.Source: §2.5 · p. 8
  • Cost-aware artifact materialization is proposed for bounded-loss unattended execution.The surrounding discussion names MCP capability attestation, trust propagation, profile caps, and REST publication governance as related concerns.Source: §2.5 · p. 8

3 Problem Formulation: From Capability to Reliable Capability

Reliable capability means reaching a task goal through at least one trace whose every action event satisfies applicable constraints. It is stronger than raw capability but does not require rejecting actions that meet those constraints.

3 Problem Formulation: From Capability to Reliable Capability

  • Reliability is assessed over execution paths because correct answers may conceal unauthorized data access, unsafe delegation, memory changes, unrecoverable spending, or missing audit trails.The trace records runtime states, agent actions, and observations; actions include reasoning, tool or service calls, memory operations, data retrieval, publication, and delegation.Source: §3 · p. 8
  • Raw capability is existential: one executable trace can reach the goal, without constraining the path used to reach it.A runtime that blocks every action may be safe but not useful, while completing tasks by any means does not ensure trustworthiness.Source: §3 · pp. 8–9
  • Every action event must satisfy identity, role, profile, data, memory, tool, budget, artifact, approval, and audit predicates; any failed predicate makes the action unreliable.These obligations apply to each event in the execution trace.Source: §3 · p. 9
  • Delegation may tighten profiles, narrow tools and memory scope, and reduce budget, but it may not widen authority inherited from the caller.The delegation condition prevents profile laundering and authority widening across call chains.Source: §3 · p. 9
  • An agent is reliably capable when at least one goal-reaching trace is reliable, with reliability required universally across the selected trace’s action events.The goal condition is existential over traces, while reliability is universal over action events.Source: §3 · pp. 8–9
  • Hard-policy deployments require every failure term to be zero; risk-scoring deployments may use a weighted sum only after hard feasibility is checked.Failure classes include wrong authority, overbroad tools, data leakage, memory contamination, profile laundering, unrecoverable cost without output, unapproved external action, and missing traceability.Source: §3 · p. 10

3.1 Conditional Correctness and Context Perception

  • The correctness guarantee is conditional on correct context facts: unsafe execution can also result from errors in observed metadata or classification before the policy gate decides.The policy algebra targets decision correctness given correct identity, policy, tool, data, memory, budget, artifact, and approval facts; context errors include misclassified documents, stale metadata, and missing action-risk tags.Source: §3.1 · pp. 10–11

4 System Model

The system models profiles as ordered assurance regimes whose joins select stricter obligations, while effective authority remains bounded by intersections with identity, configuration, data policy, and publication state.

4 System Model

  • Profiles form an ordered set from Low through VeryHigh, with joins selecting the more restrictive profile and meets the less restrictive one.The order represents increasing assurance and restriction, not an independent grant of business privilege or data clearance.Source: §4 · p. 11
  • Each profile policy Γ(p) specifies model, tool, data, memory, retention, budget, artifact, approval, exposure, schema, and audit requirements.These dimensions are represented as Γ(p) = (Mp, Tp, Cp, Θp, τp, Bp, Qp, Hp, Ep, Sp, Ap).Source: §4 · p. 11
  • A higher profile can require stronger validation, isolation, approval, and evidence, but cannot authorize resources forbidden by governing identity or policy constraints.Effective authority is obtained through intersections, preventing stronger assurance from being mistaken for broader entitlement.Source: §4 · p. 11
  • The runtime maps users, teams, accounts, applications, clients, workflows, agents, and services together with resources and profiles into action decisions.Resources include tools, connectors, knowledge sources, memory stores, models, APIs, and service endpoints.Source: §4 · p. 11

5 Preliminaries

The preliminaries establish policy-bounded reliable execution, formalizing how governance context and delegated authority constrain action selection while independent constraints and obligations compose without losing evidence. They define how residual risk, budget, artifact, approval, and tool rules preserve recoverability and propagate across delegated call paths.

5 Preliminaries

  • The preliminaries require governance additions to preserve monotonicity, delegated authority to narrow, independent policy families to agree, and approval and evidence obligations to propagate.They also require risk estimates to guide ranking rather than override feasibility, and unattended execution to avoid exhausting budget without a recoverable artifact; these principles adapt established protection, information-flow, and role-based access ideas to dynamic agent actions.Source: §5 · pp. 11–12

5.1 The Policy Algebra

  • Policy composition combines stricter profiles and materialization, intersects tool and memory authority, minimizes budget, and accumulates approval and evidence obligations.It is trust-preserving and the least-restrictive sound upper bound of its governing states; the runtime admits actions that satisfy encoded feasibility and risk constraints, leaving utility optimization to the reasoner.Source: §5.1 · pp. 13–14

5.2 Profile Cascade

  • The effective profile is the strictest profile induced by platform, team, user, agent, and publication scopes, so adding a governing scope cannot reduce assurance.No lower layer may loosen inherited constraints.Source: §5.2 · p. 14

5.3 Policy-Intersected Tool Authorization

  • Tool calls are governed transactions whose authorization intersects identity, agent/workflow, service, threat-layer, data, budget, artifact, and approval policies.The authorization predicates apply to the requested tool or service and its parameters in the initiating identity and agent/service context.Source: §5.3 · p. 15

5.4 RAG and Memory Access

  • Retrieved context and memory writes are admissible only under profile-bound classification, access, scope, purpose, ownership, retention, and sanitization rules.RAG and memory access are bound to the same profile algebra that governs tools.Source: §5.4 · p. 15

5.5 Trust-Preserving Delegation

  • Delegation inherits restrictions through profile joins, authority intersections, and minimum budgets; branching calls additionally require atomic budget reservation to prevent concurrent children from duplicating parent budget.The resulting profile cannot be weaker than either caller or callee, and allocated parent-plus-child budgets cannot exceed the parent’s remaining budget.Source: §5.5 · pp. 16–17

5.6 Multi-Agent Extension

  • For a multi-agent call path, the path profile is its strictest profile and its tool authority is the tools common to all nodes; admissibility also depends on call depth and approval evidence.The call graph is represented as agents or services connected by directed calls.Source: §5.6 · p. 17

5.7 Residual Risk Model

  • Residual risk decomposes threat likelihood, impact, and exposure remaining after profile-activated controls, while risk ranks feasible actions rather than relaxing hard constraints.Examples of controls include sandboxing, human approval for high-impact external actions, and memory scoping; the exposition identifies threat-model mappings, action type, tool criticality, data classification, call depth, and external exposure as possible estimation inputs.Source: §5.7 · pp. 17–18
  • Residual risk is decomposed into estimable components, potentially updated with telemetry, and used to rank feasible alternatives and set review thresholds; policy constraints remain hard requirements.The estimator is implementation-dependent, and an imprecise estimate cannot authorize an action that violates policy.Source: §5.7 · pp. 18–19

5.8 Valid Artifacts and Recoverability

  • A valid artifact must meet workflow-specific operational checks; when a cost bound is unavailable, threshold-based redirection approximates the reserve rule.Examples include a persisted ticket identifier and status, a validated report schema with source references, or a checkpoint sufficient to resume without repeating the full cost.Source: §5.8 · p. 19
  • Under the stated cost, reserve-update, and availability assumptions, non-materializing actions cannot consume the capacity reserved to attempt a valid artifact.This preserves capacity to attempt materialization, but does not guarantee artifact success; that still depends on the materializer and storage boundary.Source: §5.8 · p. 19

5.9 Controlled Action Selection

  • The runtime selects for utility only among admissible actions, while budget limits prevent overspend and materialization rules redirect exposed, artifact-free runs toward a recoverable output.The stop-loss allows research, retrieval, and planning while cost exposure remains acceptable; once exposure is material and no artifact exists, it redirects action toward a draft or checkpoint.Source: §5.9 · p. 20

5.10 Consequences of the Algebra

  • Approval required at any node cannot be bypassed by delegation, and effective tool authority along a call path is the intersection of its nodes’ tool sets.Source: §5.10 · pp. 20–21

6 Enterprise Runtime Architecture

The architecture separates reusable agent patterns from production enforcement and places policy checks at runtime boundaries. It combines action admission with cost and artifact-state controls to govern execution, especially in unattended workflows.

6 Enterprise Runtime Architecture

  • The platform separates reusable framework patterns, runtime system-of-record enforcement, and application interfaces, with services spanning identity, policy, tools, data, audit, cost, artifacts, and deployment.This separation keeps reusable agent design distinct from production enforcement.Source: §6 · pp. 21–22
  • Budget tracking records costs at reasoning, tool, model, and workflow steps, while artifact tracking identifies durable outputs and redirects further open-ended work toward materialization.Runs with substantial budget consumption but no recoverable artifact are treated as unsafe payoff states; in unattended workflows, the runtime enforces the stop-loss.Source: §6 · p. 22
  • Runtime actions are admitted only when identity, role, profile, data, memory, tool, budget, artifact, approval, and audit predicates jointly hold; decisions emit trace evidence.The runtime compiles standards, threat findings, enterprise context, and metadata into a monotone policy state, supporting repair and regression testing.Source: Figure 3 · p. 23

6.1 Implementation Sketches

  • Implementation sketches configure profiles and audit evidence, then gate tool calls on role, agent, publication, layer, data, budget, and approval checks.The sketches include profile-scoped memory and approval requirements for external writes or destructive actions.Source: §6.1 · pp. 23–24

7 Threat-to-Control Mapping

Threat findings are translated into executable controls by assigning each affected action a mitigation, minimum security profile, runtime gate, and required evidence. The runtime checks the gate before execution and records evidence for allow, deny, and approval outcomes.

7 Threat-to-Control Mapping

  • Each threat finding maps to a mitigation family, minimum required profile, executable runtime gate, and evidence set for the affected action.The runtime evaluates the gate before the action executes.Source: §7 · p. 24
  • Evidence is recorded for allow, deny, and approval outcomes, while Table 4 presents the threat-to-control mapping and audit evidence.The mapping converts threat findings into predicates, profile floors, and evidence obligations.Source: §7 · pp. 24–25, Table 4 · p. 25
  • For unexpected remote-code-execution findings involving KC6 operational-environment components, controls include sandboxing, command allowlisting, network isolation, and a High or Very High profile floor.Execution is denied or requires approval, with audit evidence for the actor, command, sandbox, approval state, and profile.Source: §7 · p. 25

8 Evaluation Methodology

The evaluation measures conformance to the proposed controls, invariants, executable predicates, and evidence requirements rather than ranking performance on a public benchmark. Its protocol separates design coverage, runtime enforcement, adversarial scenarios, and policy repair.

8 Evaluation Methodology

  • The evaluation asks whether security artifacts map to runtime controls, compile into predicates or gates, block unsafe tools, and prevent profile laundering during delegation.The runtime comparison uses the same workload, metrics, and scenario categories for the proposed policy-algebra runtime and an RBAC-and-allowlist comparator.Source: §8 · p. 26
  • It also tests whether logs support governance reconstruction, materialization reduces budget exhaustion without durable output, and failed cases yield policy updates and regression tests.These are the evidence, bounded-loss execution, and repair questions in the protocol.Source: §8 · p. 26
  • Coverage requires each checked artifact class to have an enforcement, monitoring, or audit path, but coverage alone does not prove security.The artifact set includes AISVS categories, NIST AI RMF functions, MAESTRO layers, threat and component classes, and architecture patterns.Source: §8 · pp. 27–28
  • Interventions include denials, approvals, sandboxing, restrictions, and materialization redirects; trust violations count strict profile downgrades across delegation chains.Because approval and materialization are interventions, results indicate immediate execution prevented or constrained, not necessarily permanently rejected.Source: §8 · p. 28
  • Audit completeness compares required and logged event fields, while zero-artifact exhaustion tracks budget-exhausted runs lacking durable output; failed cases feed policy repairs.Repairs can include stricter profile floors, narrower tool allowlists, new approval rules, memory restrictions, materialization thresholds, audit requirements, or regression tests.Source: §8 · pp. 28–29

9 Preliminary Design Evaluation

The preliminary design evaluation checks whether the policy algebra provides executable controls for security-artifact classes and represents its central invariants, while identifying gaps that motivate runtime evaluation.

9 Preliminary Design Evaluation

  • The evaluation checks that each security-artifact class has an executable runtime control path, as a prerequisite for runtime tests.It is separate from the runtime measurements in Section 11.Source: §9 · p. 29
  • It also checks whether central algebra invariants are represented in the policy algebra and implementation design.Source: §9 · p. 29
  • The evaluation identifies three gaps: mapped controls may not fire on every path, enforcement assumes correct metadata, and memory or retrieval influence can persist after exact-text filtering.These gaps motivate the runtime evaluation protocol in Section 10.Source: §9 · p. 30

10 Runtime Evaluation Protocol

The protocol defines executable conformance tests in which each case specifies an actor, agent, profile, action, expected decision, and expected audit record. Its test sketches cover trace evaluation and controls for tool misuse, delegated profiles, data access, publication changes, and budget-aware artifact materialization.

10.1 Trace Evaluation

  • Trace evaluation counts unsafe attempts and intervened unsafe events, profile-monotonicity violations when cost_after exceeds budget, budget violations when exhaustion occurs without an artifact, and zero-artifact exhaustions when required human approval is absent.Source: §10.1 · p. 31

10.2 Tool Misuse Test

  • A Medium-profile viewer’s attempt to delete a record is denied for a role, agent-allowlist, or profile failure, with the decision recorded in the audit.The test agent’s allowlist contains only search.Source: §10.2 · p. 31

10.3 Profile Laundering Test

  • The profile-laundering test requires a child context to retain the effective High profile, restrict email access or require human approval, and record the parent-child chain in the audit.Source: §10.3 · p. 32

10.4 RAG Access-Control Test

  • The RAG access-control test excludes a restricted HR-scoped document from a finance-scoped result and records a RAG access-denied policy event.Source: §10.4 · p. 32

10.5 Publication-Profile Test

  • After publication, a profile change triggers a review-required decision with reason profile_change_after_publication and a service audit event.Source: §10.5 · p. 32

10.6 Artifact Materialization Test

  • Before budget exhaustion, the materialization test requires redirect or restriction, specifies materialize_artifact as the required action, and records the requirement in the audit.Source: §10.6 · p. 33

11 Results and Discussion

The policy-algebra runtime increased unsafe-action intervention and audit completeness while retaining most task completion, at the cost of more false interventions and latency; the finite-workload results do not establish universal security.

11 Results and Discussion

  • The policy-algebra runtime intervened on 798/842 unsafe events (94.8%), versus 565/842 for the RBAC-and-allowlist comparator, through denials, approvals, and artifact redirects.The 798 interventions comprised 619 denials, 121 required-approval decisions, and 58 artifact-materialization redirects; intervention means preventing immediate unrestricted execution, not permanently rejecting every action.Source: Figure 6 · p. 35, Table 10 · p. 35, §11 · p. 36
  • Task completion decreased by 3.8 percentage points, from 90.7% to 86.9%; false intervention rate rose from 2.1% to 4.2%, and median authorization latency from 38 ms to 71 ms.The governed runtime retained 95.8% of the comparator’s completion rate on this workload; the comparisons are descriptive, not causal estimates or universal exchange rates.Source: Figure 6 · p. 35, Table 10 · p. 35, §11 · p. 37
  • Profile monotonicity violations fell from 31 under the comparator to zero; zero-artifact budget exhaustions fell from 18 budget-only runs to zero, and audit completeness rose from 71.9% to 98.6%.Recording identity, profile, decisions, data, approvals, budget, artifact state, call-chain lineage, and result hashes makes failed cases easier to reproduce, review, and repair.Source: Figure 6 · p. 35, Table 10 · p. 35, §11 · pp. 37–38
  • Residual misses reflect context errors such as misclassification or stale metadata, while hard constraints—not risk scores—define the safety boundary; finite conformance results do not establish universal security.Risk scores rank feasible alternatives and guide review thresholds; residual misses locate the boundary of formal guarantees for correctly represented contexts.Source: Figure 7 · p. 36, Table 11 · p. 36, §11 · pp. 37–38
  • The largest observed gains arose where user or tool permission alone missed profile, data, publication, budget, artifact, HITL, or delegation constraints, motivating joint policy-conjunction decisions.Each denial can be traced to a failed factor, unlike authorization based only on a tool allowlist or human-user RBAC check.Source: §11 · p. 37
  • Delegation is a security event: caller trust must pass to the callee, and a lower-security callee must operate under the stricter effective profile and narrowed authority.Under correct context construction and atomic enforcement, this rules out the specific privilege-bypass mechanism in which delegation weakens caller security; it does not solve all multi-agent risk.Source: §11 · p. 37
  • Cost-aware materialization redirects runs without recoverable artifacts toward a draft, checkpoint, or durable output before budget exhaustion, addressing a failure budget-only enforcement can permit.Zero observed exhaustion establishes conformance only for tested conditions, not semantic artifact quality; preserving capacity for materialization depends on the assumptions in Equation (30).Source: §11 · p. 38
  • Governed retrieval checks classification, access, scope, and purpose, while memory writes check classification, ownership, scope, retention, and sanitization; published service profiles remain frozen until a change triggers review.Publication-time profile freezing preserves the approved security state for MCP or REST consumers at runtime.Source: §11 · p. 38

12 Policy Repair and Regression Testing

Policy repair turns evaluation failures into stronger policy rules and regression tests, making evaluation part of the enforcement control loop. Repairs can update profiles, tool restrictions, memory and publication rules, materialization thresholds, HITL requirements, and audit requirements.

12 Policy Repair and Regression Testing

  • Failed cases induce new or strengthened policy rules, and are added to the regression suite as future tests.The repair function updates the policy set from failed cases, while the suite grows by adding those cases.Source: §12 · p. 39
  • A failed test can trigger updates to profiles, tool restrictions, memory, publication, materialization thresholds, HITL rules, audit requirements, or regression cases.This makes evaluation part of the control loop.Source: §12 · p. 39
  • Repairs include adding tool-profile floors and HITL rules for unsafe tools, enforcing profile joins in delegation, and lowering materialization thresholds after artifact-free budget exhaustion.The listed regression cases include blocked-tool, delegation-profile, and budget-exhaustion tests.Source: §12 · pp. 39–40

13 Limitations and Future Work

The paper presents its guarantees as conditional on represented policies and contexts, and its experiments as finite-workload measurements rather than complete security proofs. It identifies metadata, policy-model, multi-agent, artifact, and evaluation limitations that motivate further work.

Limitations and Future Work

  • The algebra provides conditional trust-preservation and least-restrictive composition for correctly represented policies and contexts, not a complete proof of system security.It does not establish that runtime context is perceived correctly, all relevant predicates are specified, or the gate cannot be bypassed; further formal work is needed on dynamic-call-graph non-escalation, audit reconstruction, and monotonicity under policy updates.Source: §13 · p. 40
  • Incorrect metadata for data, services, tools, memory, or endpoints can cause wrong policy decisions, motivating attestation and continuous classification validation.Proposed directions include metadata attestation, signed tool registries, cryptographic service attestations, and continuous data-classification validation.Source: §13 · p. 40
  • The paper’s simple profile set may not represent organizations with domain-specific incomparable profiles, motivating richer lattices, type systems, and predeployment policy simulation.Safety-critical and privacy-critical profiles may be incomparable rather than linearly ordered.Source: §13 · p. 40
  • Classifier-dependent predicates can fail, so production runtimes should treat prompt-injection, sensitivity, provenance, and output-safety classifications as uncertain evidence rather than truth.The conformance procedure assumes many policy predicates are available and sufficiently deterministic.Source: §13 · p. 40
  • The multi-agent extension covers call chains and delegation edges, but budget non-amplification assumes atomic fan-out reservations and does not resolve more complex interaction patterns.Concurrent branching, negotiation, broadcast, shared memory, and cycles motivate graph-level trust analysis, transactional budget allocation, and possibly fixed-point semantics.Source: §13 · p. 40
  • The zero-artifact metric shows durable output before exhaustion under tested conditions, but does not establish semantic recoverability or validate artifact quality.Artifact-quality scoring and workflow-specific validity tests are needed; other partial elements include deterministic regulated-workflow tooling, scaled asynchronous approval queues, immutable audit storage, and advanced cross-session memory controls.Source: §13 · pp. 40–41
  • The measurements show conformance and a reliability–capability trade-off on the stated workload, not universal attack resistance or benchmark superiority.Further evaluation should use repeated runs, uncertainty intervals, larger independent workloads, red-team scenarios, enterprise traces, concurrent delegation, and service publication; report task success, unsafe and false interventions, attack success, latency, cost, valid-artifact exhaustion, audit completeness, and profile-monotonicity violations.Source: §13 · p. 41

14 Conclusion · Declarations

The conclusion presents policy algebra as a correctness-oriented way to retain useful agent capability within an authorized, recoverable, and auditable execution envelope, while acknowledging measured trade-offs. The declarations report funding, interests, ethics, and data availability.

14 Conclusion

  • The method compiles standards, threat models, and governance artifacts into runtime predicates, then composes them into an envelope that tightens profiles, narrows authority, reserves budget, and accumulates obligations and evidence.The stated aim is to preserve useful autonomy while keeping actions authorized, non-amplifying under delegation, economically recoverable, and auditable.Source: §14 · p. 41
  • Reliable capability requires every governed action in a goal-reaching trace to satisfy identity, role, profile, data, memory, tool, budget, artifact, HITL, and audit constraints.Composition is both trust-preserving, so obligations cannot be weakened, and least restrictive, so authority is not removed beyond what those obligations require.Source: §14 · p. 41
  • Multi-agent calls propagate trust through profile joins, tool intersections, budget conservation, narrowed memory scope, and inherited approval obligations.The method also orders profiles as policy objects, authorizes tools through intersected predicates, and freezes service publication under reviewed profile state.Source: §14 · p. 41
  • The workload showed stronger unsafe-event intervention, zero observed profile and zero-artifact violations, and more complete audit evidence, but higher false intervention and latency and 3.8-percentage-point lower task completion.The conclusion presents this as a measured reliability-capability trade-off, not unrestricted benchmark superiority.Source: §14 · p. 41
  • The conclusion proposes expanding the reliability envelope through better context perception and policy calibration without weakening its invariants.The method is presented as a falsifiable path toward improving both reliability and task capability.Source: §14 · p. 41

Declarations

  • The authors received no funding for the submitted work and report no relevant financial or non-financial interests.These are the funding and conflict-of-interest declarations.Source: Declarations · p. 41
  • The article reports no studies involving human participants or animals performed by the authors.This is the article's ethical approval declaration.Source: Declarations · p. 41
  • The datasets generated and analyzed for the study are available in the PolicyAlgebra GitHub repository.The declaration identifies https://github.com/bhaskatripathi/PolicyAlgebra.Source: Declarations · p. 42

Appendix … A3 Detailed Mapping from Standards to Runtime Effects

The appendix summarizes notation, describes security-profile dimensions and their runtime interpretation, and maps external security artifacts to runtime effects and evidence.

A1 Notation Summary

  • Table A1 summarizes notation used in the paper and appendices.Source: Table A1 · p. 45
  • The notation summary covers both the paper and its appendices.Source: Table A1 · p. 45

A2 Security Profile Specification

  • Table A2 presents security-profile dimensions.Source: Table A2 · p. 46
  • Table A2 gives representative runtime interpretations of the profile dimensions.Source: Table A2 · p. 46

A3 Detailed Mapping from Standards to Runtime Effects

  • Table A3 crosswalks external security artifacts to executable runtime effects.Source: Table A3 · p. 46
  • The Table A3 crosswalk also connects external security artifacts with evidence.Source: Table A3 · p. 46

Related papers

Loading 2608.16402v1…