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 AI’s ability to act creates reliability and security requirements beyond conventional access control and prompt defenses. This paper introduces a policy algebra for trust-preserving execution, whose runtime intervenes on 94.8% of unsafe events while retaining 86.9% task completion and eliminating observed profile-monotonicity and zero-artifact-exhaustion violations.

  • Problem

    Agentic systems connect language-model reasoning to tools, data, memory, workflows, and delegation, requiring controls beyond application access checks and prompt-level defenses.

  • Method

    The paper defines a policy algebra that composes security profiles and runtime obligations while propagating restrictions, enforcing recoverable artifacts, and accumulating audit evidence.

  • Results

    The runtime intervened on 94.8% of unsafe events and retained 86.9% task completion, while observed profile-monotonicity and zero-artifact budget-exhaustion violations fell to zero and audit completeness reached 98.6%.

  • Takeaways & Limitations

    The policy algebra provides formal structure and evidence for governing agents that cross organizational boundaries through authorized, bounded, recoverable, approved, and auditable actions.

  • Takeaways & Limitations

    The guarantees are conditional on correctly represented policies, contexts, and enforcement assumptions, while the experiments measure finite workloads.

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 paper frames reliable capability as completing goals through universally admissible action paths, rather than merely producing useful outputs. It proposes an executable policy algebra that composes enterprise controls, constrains delegation and cost exposure, and turns security guidance and evidence obligations into runtime decisions.

  • 1 Introduction: Agentic systems can search, retrieve data, call tools and APIs, update memory, create side effects, and delegate work, making security an action-execution problem.The paper emphasizes the transition from model output to state-changing operations across tool-rich and multi-agent environments.
  • 1 Introduction: Reliable capability requires every event in the action sequence to remain admissible under identity, authority, policy, data, memory, approval, budget, artifact, and audit constraints.The protected object is often a transition from a model-generated proposal to an action, while authorization state changes across execution steps.
  • 2 Background and Related Work: Existing standards, threat models, benchmarks, testbeds, runtime defenses, and governance frameworks identify risks and controls but do not specify one enterprise execution semantics.The paper positions AISVS, NIST AI RMF, MAESTRO, AgentDojo, Agent Security Bench, ClawGuard, DRIFT, NeuroTaint, AGENTSAFE, and MI9 as complementary foundations.
  • 1 Introduction: Runtime enforcement must be compositional, non-amplifying under delegation, bounded against unrecoverable budget exhaustion, and capable of producing evidence for decisions and effects.Required interventions include denying or redirecting calls, escalating to humans, redacting outputs, or freezing execution when predicates fail.
  • 1 Introduction: The proposed algebra composes enterprise profiles, RBAC, tools, memory, publication, budget, approval, and evidence obligations into the least restrictive policy state satisfying all governing inputs.Its execution semantics use profile joins, authority intersections, budget narrowing, approval inheritance, and recoverable-output obligations.
  • 2.1 Agentic AI and Multi-Agent Systems: Multi-agent delegation can widen authority when child contexts differ from callers, so the runtime propagates restrictions through monotone profile joins and narrowing of tools, budget, and memory.The child context must not be less restrictive than the parent context.
  • 2.4 Agentic Identity and Access Management: Authentication establishes identity but does not determine execution authority, which must still be narrowed by profile, memory, tool, publication, budget, artifact, approval, and delegation constraints.The execution layer operates after agent authentication and base authorization are established.
  • 2.5 Cost-Aware Execution and Bounded-Loss Design: Cost-aware materialization redirects unattended execution toward a durable draft, checkpoint, file, record, or partial result when cost exposure becomes material and no artifact exists.This treats bounded-loss behavior as a platform-enforced property and avoids budget exhaustion without a recoverable output.

3 Problem Formulation: From Capability to Reliable Capability

Reliable capability requires both achieving the task goal and following an admissible execution path. The formulation makes reliability universal over action events and conditional on correctly observed execution context.

  • 3 Problem Formulation: From Capability to Reliable Capability: Reliable capability requires goal achievement through an admissible path, unlike raw capability, which only requires one executable trace reaching the goal.Capability is existential over traces, whereas reliability constrains the selected trace.
  • 3 Problem Formulation: From Capability to Reliable Capability: The execution trace is the primitive analysis object, containing runtime states, actions, and observations returned by models, tools, memory systems, services, or environments.Actions include reasoning, tool calls, data retrieval, publication, memory operations, and delegation.
  • 3 Problem Formulation: From Capability to Reliable Capability: Every action event must satisfy identity, role, profile, data, memory, tool, budget, artifact, approval, and audit obligations.A single failed predicate makes the action unreliable.
  • 3 Problem Formulation: From Capability to Reliable Capability: Delegation may tighten profiles, tools, memory, and budgets, but it cannot widen the caller’s inherited authority.The multi-agent condition prevents profile laundering and authority widening across call chains.
  • 3 Problem Formulation: From Capability to Reliable Capability: Hard-policy deployments require every failure term to be zero, while weighted risk scoring is permitted only after hard feasibility has been checked.Reliable execution requires F(ξ) = 0 for hard security constraints and requires the delegation condition for all delegation edges.
  • 3.1 Conditional Correctness and Context Perception: Conditional correctness guarantees policy invariants only when identity, policy, tool, data, memory, budget, artifact, and approval facts are correctly observed.Misclassified documents, ambiguous tool intent, stale metadata, incomplete command classification, and missing risk tags belong to the observation boundary.

4 System Model

The system model represents profiles as ordered risk regimes whose increasing assurance obligations compose through restrictive joins and permissive meets. Each profile defines policy constraints, while effective authority remains bounded by identity, configuration, data, and publication intersections.

  • Profiles: Profiles form the ordered set P = {Low, Medium, High, VeryHigh}, with higher positions imposing greater assurance and restriction.The ordering describes risk regimes in which moving upward increases assurance obligations.
  • Profiles: The join pi ⊔ pj selects the more restrictive profile, whereas the meet pi ⊓ pj selects the less restrictive profile.These operations provide the profile composition rules for combining assurance regimes.
  • Profile policy objects: Each profile policy object specifies models, tools, data classes, memory scope, retention, budget, artifacts, approvals, exposure, schemas, determinism, and audit depth.The policy tuple is Γ(p) = (Mp, Tp, Cp, Θp, τp, Bp, Qp, Hp, Ep, Sp, Ap).
  • Authority and runtime: A higher profile cannot independently authorize resources or tools; effective authority is obtained through intersections governing initiating identity, agent configuration, data policy, and publication state.Higher profiles may require stronger validation, isolation, approval, and evidence without granting business privilege or data clearance.
  • Authority and runtime: The runtime maps identities, resources, and profiles into decisions over actions.Identities include users, teams, service accounts, applications, clients, workflows, agents, and services; resources include tools, sources, stores, models, APIs, and endpoints.

5 Preliminaries

The policy algebra defines reliable execution as a monotone, trust-preserving path property: added governance and delegation can only narrow authority while accumulating obligations. Its runtime enforces a least-restrictive reliability envelope that preserves approval, evidence, budget, and recoverable-artifact requirements.

  • Security principles: Governance composition is monotone: added context cannot widen permissions, and delegated authority must narrow across execution boundaries.The framework states monotonicity as a guiding requirement and treats delegation as inherited restriction rather than fresh authority.
  • Policy composition: Policy composition intersects tools and memory scopes, selects the smaller budget, strengthens profiles and materialization policies, and accumulates approval and evidence obligations.These operators ensure composition cannot add tools, broaden scope, increase budget, weaken artifact requirements, remove approval, or remove audit obligations.
  • Policy composition: The composed state is the least upper bound satisfying both governing inputs without imposing restrictions absent from their components.The least-upper-bound property establishes trust preservation while retaining the least restrictive state that satisfies all inputs.
  • Reliability envelope: The admissible set is the reliability envelope: the runtime excludes policy-violating actions while leaving the reasoner free to optimize utility among actions satisfying declared feasibility and risk constraints.This is maximal permissiveness relative to the encoded policy, not a claim that the policy itself is complete.
  • Delegation: Delegation preserves or strengthens effective profiles, caps aggregate child allocations by the parent’s remaining budget, prevents approval bypass, and narrows tools along every call path.The delegation lemmas establish profile monotonicity, non-amplification of allocated budget, inherited approval requirements, and pathwise tool restriction.
  • Recoverable execution: When cost exposure becomes material without a durable artifact, the stop-loss redirects admissible actions toward a recoverable draft or checkpoint, preserving reserved capacity for artifact production.The guarantee assumes upper-bounded cost estimates, atomic reserve updates, and an available artifact-producing action within the reserved capacity.

6 Enterprise Runtime Architecture

The enterprise runtime architecture realizes the policy algebra by separating reusable framework patterns, production enforcement, and tenant-facing applications. It enforces joint identity, policy, resource, approval, budget, artifact, and audit constraints while governing unattended workflows through cost-aware artifact tracking.

  • Architecture Layers: The platform separates reusable agent blueprints, runtime enforcement as the system of record, and application interfaces and tenant workflows.This separation keeps reusable design patterns distinct from production enforcement.
  • Platform Services: Core services cover agent registration, profiles and RBAC, orchestration, tools, knowledge, memory, governance, auditing, monitoring, costs, artifacts, and deployment.Cross-cutting controls include IAM, policy enforcement, compliance, quotas, privacy, approvals, and continuous verification.
  • Cost and Artifact Governance: Cost governance records execution costs while artifact tracking detects durable, recoverable outputs, treating substantial budget use without an artifact as unsafe.In asynchronous enterprise workflows, the runtime—not the model—enforces the stop-loss.
  • Runtime Enforcement: Each proposed action is admitted only when identity, profile, data, memory, tool, budget, artifact, approval, and audit predicates jointly hold.Denials, approvals, redirects, and executions emit trace evidence for repair and regression testing.

7 Threat-to-Control Mapping

Threat findings are converted into executable policy controls by assigning each finding a mitigation family, minimum profile, runtime gate, and evidence obligation. The runtime evaluates the gate before action execution and records evidence for allow, deny, and approval outcomes.

  • Threat-policy compilation: Threat findings become actionable by being converted into predicates, profile floors, and evidence obligations.This conversion links threat analysis to enforceable runtime behavior.
  • Threat-policy compilation: Each finding maps to a mitigation family, minimum required profile, executable runtime gate, and evidence set.The runtime gate is evaluated before the affected action executes.
  • Threat-to-control example: For unexpected remote-code execution 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 covering actor, command, sandbox, approval state, and profile.

8 Evaluation Methodology

The evaluation tests conformance to the proposed policy-algebra controls, predicates, invariants, and evidence requirements rather than ranking benchmark performance. It combines coverage analysis, runtime trace decisions, audit reconstruction, bounded-loss measures, and policy repair.

  • Evaluation basis: Evaluation validity is defined by conformance to the control taxonomy, policy invariants, executable predicates, and evidence requirements rather than public benchmark ranking.The protocol evaluates the proposed runtime against an RBAC-and-allowlist comparator using the same evaluation framework.
  • Research questions: The evaluation examines tool safety, delegation monotonicity, audit reconstruction, bounded-loss execution, and policy repair through seven research questions.The questions cover unsafe tool paths, profile downgrades and laundering, reconstructable evidence, zero-artifact budget exhaustion, and conversion of failed cases into policy updates and regression tests.
  • Coverage and compilation: The protocol asks whether security artifacts map to executable controls and whether each mapped control compiles into predicates, gates, audit fields, profile floors, or regression tests.Coverage requires at least one enforcement, monitoring, or audit path for each artifact class, but coverage alone is not proof of security.
  • Runtime decisions: Runtime conformance measures whether policy-violating actions are denied, approved, sandboxed, restricted, or redirected to artifact materialization, while distinguishing constrained execution from permanent rejection.An intervention occurs whenever the runtime decision is not Allow.
  • Policy repair: Failed evaluation cases feed back into the policy set as stricter floors, narrower allowlists, new approvals, memory restrictions, materialization thresholds, audit requirements, or regression tests.The evaluation produces a coverage matrix, weakly covered or uncovered cases, and policy repair actions.

9 Preliminary Design Evaluation

The preliminary design evaluation verifies whether the policy algebra and runtime provide executable control surfaces for each security-artifact class and represent the algebra’s central invariants. It also identifies gaps that motivate runtime evaluation, including unproven attack resistance, dependence on correct metadata, and persistent semantic influence through memory and retrieval.

  • Control-surface coverage: The evaluation checks for an executable runtime control path for each security-artifact class.Its purpose is to establish sufficient control surfaces for later runtime tests, not to report runtime measurements.
  • Invariant representation: The next check evaluates whether the policy algebra and implementation design represent the algebra’s central invariants.
  • Remaining gaps: Three gaps remain: mapped controls do not prove attack resistance, enforcement depends on correct metadata, and semantic influence can persist after exact-text filtering.Misclassified tools or data objects can weaken enforcement, while memory and retrieval may preserve semantic influence.

10 Runtime Evaluation Protocol

The runtime protocol makes the policy algebra testable through executable conformance tests over action events. Each test specifies an actor, agent, profile, action, expected decision, and expected audit record across conformance, red-team, production-like, and optional comparative workloads.

  • Protocol design: Each conformance test specifies an actor, agent, profile, action, expected decision, and expected audit record.The protocol targets the authors’ conformance workload, internal red-team cases, production-like service-publication workflows, and optional external datasets for comparative context.
  • Conformance tests: Blocked tool-call tests verify denial and identify whether role, agent allowlist, or profile caused the failure, with the decision recorded in audit.The sketch uses a viewer, a Medium-profile agent limited to search, and a delete-record action.
  • Conformance tests: Profile-laundering tests require the effective profile to remain High, restrict email access or require human approval, and audit the parent-child chain.This test checks that delegated execution cannot silently weaken inherited restrictions.
  • Conformance tests: RAG access-control tests deny a restricted HR document to a finance-scoped viewer and record a rag_access_denied policy event.The document is marked restricted, scoped to HR, and sourced from SharePoint.
  • Conformance tests: Publication-freeze and cost-aware materialization tests require review after publication-profile changes and redirect or restrict execution to materialize an artifact before budget exhaustion.Both decisions must be represented in the audit trail through service or run-level events.

11 Results and Discussion

The evaluation shows that policy-algebra enforcement substantially reduces unsafe execution and trust violations while preserving meaningful task completion, auditability, and recoverable outcomes. Results also position security as a trace property governed by hard constraints, with residual misses arising from context-construction and interpretation errors.

  • Security–capability trade-off: 94.8% of unsafe events were intercepted, compared with 67.1% under RBAC-and-allowlist enforcement, through denials, approvals, and artifact-materialization redirects.The proposed runtime intervened on 798 of 842 unsafe events, versus 565 of 842 for the comparator.
  • Security–capability trade-off: Task completion fell from 90.7% to 86.9%, while false interventions 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.
  • Trust preservation and recoverability: Profile-monotonicity violations and zero-artifact budget exhaustions both fell to zero under the proposed runtime.Delegation passes the caller’s trust context to the callee, applying the stricter effective profile and narrowed authority; cost-aware execution redirects runs toward durable artifacts before exhaustion.
  • Trace-based reliability: Security is evaluated as a trace property: every action event must satisfy policy predicates and feasibility conditions, rather than merely producing a correct-looking final answer.The runtime governs the reasoning-to-action transition and records evidence needed for review and repair.
  • Context and memory governance: Retrieval and memory writes are separately governed by classification, access, scope, purpose, ownership, retention, and sanitization constraints.Scenario-level results motivate evaluating these controls separately from ordinary tool authorization.
  • Empirical boundary: Residual misses arise from ambiguous intent, incomplete or stale metadata, misclassification, semantic poisoning, missing risk tags, and incomplete command classification.These errors concern constructing or interpreting the presented context and define the empirical boundary of the formal guarantees.

12 Policy Repair and Regression Testing

Policy repair closes the loop between evaluation and enforcement by converting failed traces into new or strengthened policy constraints. The regression suite grows with those failures, making evaluation part of the control loop.

  • Policy Repair: Failed traces become new constraints or regression cases, linking evaluation directly to policy enforcement.Repair converts failed cases into policy updates, while the regression suite adds them as future tests.
  • Regression Testing: The regression suite expands from St to St+1 by adding failed cases as future tests.This growth ensures failed evaluations are re-run after repair rather than discarded.
  • Policy Repair: Evaluation can update profiles, tool restrictions, memory rules, publication rules, materialization thresholds, HITL rules, audit requirements, or regression cases.These updates are induced by failures and applied as policy changes or future tests.
  • Regression Testing: Repair actions pair each failed case with a corrective policy change and a corresponding regression test.Examples include adding tool profile floors and HITL rules, enforcing profile joins, restricting RAG sources, requiring audit fields, and lowering materialization thresholds with checkpoints.

13 Limitations and Future Work

The policy algebra provides conditional guarantees over represented policies, contexts, and enforcement assumptions, rather than a complete proof of system security. Future work must address metadata correctness, richer policy structures, complex multi-agent execution, artifact quality, partial implementations, and broader evaluation.

  • Security guarantees: The algebra guarantees trust-preserving, least-restrictive composition only when governing policies and security context are correctly represented and enforced.It does not establish that runtime context is perceived correctly, all relevant predicates are specified, or implementations cannot bypass enforcement.
  • Metadata and evidence: Correct metadata for data, services, tools, memory, and endpoints is essential because erroneous labels, scopes, provenance, or criticality can produce wrong policy decisions.Proposed remedies include metadata attestation, signed tool registries, cryptographic service attestations, and continuous data-classification validation; classifier outputs should carry uncertainty.
  • Policy expressiveness: The intentionally simple profile set may not represent organizations requiring richer partial orders with domain-specific incomparable safety and privacy profiles.Future work should study richer lattices, type systems, and policy simulation before deployment.
  • Multi-agent execution: The multi-agent extension covers call chains and delegation edges, but more complex branching, negotiation, broadcast, shared-memory, and cyclic systems require graph-level trust analysis and transactional budget allocation.The budget non-amplification result assumes atomic reservations at fan-out; fixed-point semantics may also be needed.
  • Artifact and implementation limits: The zero-artifact metric shows durable output before exhaustion under tested conditions but does not establish artifact nontriviality, schema validity, provenance, or resumability.Artifact-quality scoring and workflow-specific validity tests are needed, alongside more complete tooling, scalable approval queues, immutable audit storage, and cross-session memory controls.
  • Evaluation scope: The measurements demonstrate 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 graphs, and service-publication workflows.

14 Conclusion · Declarations

The conclusion presents policy algebra as a correctness-oriented method for converting agent capability into reliable, auditable execution while preserving useful autonomy. The authors report no funding or relevant conflicts, no human or animal studies, and public availability of generated and analyzed datasets.

  • 14 Conclusion: The paper converts raw agent capability into reliable capability by compiling governance inputs into executable predicates and composing them at runtime.The method aims to preserve useful autonomy while ensuring actions remain authorized, non-amplifying under delegation, economically recoverable, and auditable.
  • 14 Conclusion: 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.The formal composition is both trust-preserving and least restrictive.
  • 14 Conclusion: The contribution is a correctness-oriented method for turning risk lists and security standards into executable runtime behavior without claiming unrestricted benchmark superiority.The reported trade-off combines stronger unsafe-event intervention and more complete audit evidence with higher false intervention and latency.
  • 14 Conclusion: 3.8 percentage points: the reported workload reduces task completion while increasing unsafe-event intervention, eliminating observed profile and zero-artifact violations.The conclusion frames these results as a reliability-capability trade-off rather than a capability benchmark.
  • Declarations: The authors received no funding for the submitted work from any organization.
  • Declarations: The authors disclose no relevant financial or non-financial conflicts of interest.
  • Declarations: The article contains no studies involving human participants or animals performed by the authors.
  • Declarations: The datasets generated or analyzed in the study are available in the cited GitHub repository.Repository: https://github.com/bhaskatripathi/PolicyAlgebra.

Appendix … A3 Detailed Mapping from Standards to Runtime Effects

The appendices define the paper’s notation and security-profile dimensions, then map external security artifacts to executable runtime effects and evidence. The mapping spans access control, risk treatment, tool and ecosystem security, attack techniques, privacy, and bounded-downside materialization.

  • Appendix / A1 Notation Summary: The appendices summarize notation used throughout the paper and its supporting material.
  • A2 Security Profile Specification: Security profiles organize dimensions alongside representative interpretations at runtime.
  • A3 Detailed Mapping from Standards to Runtime Effects: AISVS access-control artifacts become RBAC predicates, data-source checks, and service-invocation checks.
  • A3 Detailed Mapping from Standards to Runtime Effects: Access-control decisions are evidenced through role, resource, and decision fields.
  • A3 Detailed Mapping from Standards to Runtime Effects: NIST risk-treatment guidance produces deny, approve, revoke, profile-raising, tool-restriction, and artifact-requirement effects.
  • A3 Detailed Mapping from Standards to Runtime Effects: MAESTRO maps tool-layer controls to sandboxes, allowlists, and command filters, while ecosystem-layer controls propagate trust and limit call depth.
  • A3 Detailed Mapping from Standards to Runtime Effects: MITRE ATLAS attack techniques are operationalized through detection rules, mitigations, audit tags, and technique identifiers.
  • A3 Detailed Mapping from Standards to Runtime Effects: EU AI Act/GDPR considerations address personal data and high-risk use through data-class policies, redaction, documentation, and human-in-the-loop controls.
Loading 2608.16402v1…