ActPlane: Programmable OS-Level Policy Enforcement for Agent Harnesses
Abstract: AI agents increasingly run in production through harnesses, the software around the LLM, including an engine that enforces safety and effectiveness policies, e.g., 'run tests before committing.' Enforcing these policies requires bridging a semantic gap: policy intent is expressed in underspecified natural language, while enforcement must act on concrete system actions, e.g., which test to run. Many policies also define event ordering or data flow actions. Yet existing approaches fall short. Tool-call guardrails miss system actions that bypass the tool layer, while OS sandboxes control resource access instead of actions, returning opaque errors that confuse the agent. Our key insight is that policy context lives within the agent closest to the task, while enforcement must happen at the OS to cover all execution paths. We introduce ActPlane, a policy engine that lets agents declare policies and enforces them in the OS kernel with semantic feedback and isolation. ActPlane uses a simple information-flow control (IFC) DSL to support cross-event policies. We implement ActPlane with eBPF and evaluate it on policies from the empirical study, coding-task benchmarks, and safety benchmarks. ActPlane improves policy compliance, including on indirect execution paths that tool-call interception cannot observe, with 1.9%-8.4% overhead. ActPlane is at https://github.com/eunomia-bpf/ActPlane
Summary
- The paper introduces OS-level enforcement for agent policies via a programmable DSL compiled to eBPF, delivering robust semantic feedback.
- It empirically demonstrates superior decision compliance (75.8% DCR) over baseline systems while supporting cross-event and context-dependent policies.
- The methodology ensures safe, dynamic runtime adaptation with minimal overhead (1.9โ8.4%), confirming effective isolation in multi-agent setups.
ActPlane: Programmable OS-Level Policy Enforcement for Agent Harnesses
Motivation and Empirical Foundations
ActPlane addresses a critical gap in enforcing intent-level policies within AI agent harnesses. The empirical analysis of 64 repositories, focusing on the granularity of CLAUDE.md and AGENTS.md files, demonstrates that 64% of statements are behavioral policiesโprimarily concentrated in topics like Development Process and Implementation Details, while Architecture remains descriptive. Importantly, 83% of these policies are system-observable, with 16% requiring cross-event enforcement such as event ordering and data lineage tracking. Enforcement at the OS-level is essential, particularly since 73.6% of policies are context-dependent, meaning project and task context must be dynamically resolved by agents rather than relying on static configurations.
Existing enforcement technologies, including tool-call guardrails, application-level IFC, and OS sandboxes (seccomp, AppArmor, Landlock, Tetragon), are insufficient: tool-call guardrails miss indirect system actions (e.g., shell-outs), while OS sandboxes are limited to resource access control without semantic feedback. ActPlane bridges this gap by enabling agents to express concrete policy intent, which is then compiled and enforced at the OS kernel level, providing semantic feedback and robust enforcement across all execution paths.
Figure 1: ActPlane enables an agent to write policy DSLs communicating intent, which are compiled and enforced in the OS kernel.
ActPlane Architecture and Policy DSL
ActPlane comprises three major abstractions: a policy DSL, a kernel-level enforcement engine via eBPF, and hierarchical policy domains. The DSL is expressive yet accessible for agents, supporting sources (processes, files, endpoints), target operations (exec, read, write, connect), enforcement effects (notify, block, kill), temporal gates, and semantic feedback mechanisms.
The engine tracks information-flow control (IFC) at the object granularity. Labels propagate across process, file, and network events, providing monotonic tracking of influences and supporting the enforcement of both per-event and cross-event policies. Hierarchical policy domains ensure that agent-authored rules cannot weaken inherited (higher-authority) constraints. Runtime adaptation is achieved via kernel-side authority checking, allowing local agent rule refinements without compromising global safety properties.
Figure 2: ActPlane architecture: policy generation, compilation, kernel enforcement, and feedback loop.
Concrete examples taken from empirical repositories illustrate the DSL's coverage: per-event blocks (e.g., prohibit deleting data files), cross-event kill gates (e.g., tests-before-commit), and cross-event notify gates (e.g., regenerate code after schema migration).
Figure 3: Three DSL rule examples: per-event block (no-delete-data), cross-event kill gate (tests-before-commit), cross-event notify gate (regen-after-schema).
Implementation Details
ActPlane is implemented in Rust (userspace compiler/runner) and eBPF C (kernel engine), supporting up to 128 concurrent rules and enforcing policy across process trees and multiple OS abstractions (exec, open, read, write, connect). Label state is managed via 64-bit bitmasks and per-object BPF maps, achieving efficient propagation and enforcement. Policy updates occur through a userspace ring buffer, with kernel-side authority checks validating and merging deltas according to the domain hierarchy.
Experimental Evaluation
DSL Coverage
A translation agent (Codex, GPT-5.5) translates all 607 OS-enforceable policies into compilable ActPlane DSL rules, demonstrating accessibility and structural simplicity. Cross-event features (temporal gates, unless clauses, file sources) see substantial use, validating DSL expressiveness.
Policy Engine Effectiveness
Compared to prompt-filter, tool-regex, and tool-level IFC (FIDES), ActPlane demonstrates superior Decision Compliance Rate (DCR): achieving 75.8% DCR versus 45โ53% for baselines over 190 traces, including direct, script, and hidden violation paths. ActPlaneโs advantage is pronounced for indirect execution and cross-event policies, where kernel-level IFC and persistent session tracking outperform baselines reliant on tool boundaries.
Figure 4: Overall RQ2 Decision Compliance Rate across 190 traces under two end-to-end model settings.
Semantic feedback is critical: removal leads to fewer correct violation outcomes, underlining the efficacy of actionable kernel detection paired with feedback.
Overhead Analysis
Macrobenchmarks (agent trace replay, kernel builds) show ActPlane adds only 1.9โ8.4% end-to-end overhead in no-hit configurations, with per-syscall microbenchmarks indicating that fork and exec dominate added latency (up to 69 ฮผs at 100 rules), but overall impact is negligible compared to agent workload inference times.
Figure 5: End-to-end overhead normalized to native execution.
Real-World Coding and Safety Benchmarks
On OctoBench (21-task subset), ActPlane improves user-query and implementation/test rewards by 9.9 and 9.7 points, respectively, by enforcing OS-level DSL rules synthesized from task and repository context.
Figure 6: OctoBench 21-task subset with 61 DSL rules: reward breakdown by system.
For OpenAgentSafety (361 tasks), ActPlaneโin higher-authority mode with agent-generated policiesโblocks 74% of baseline-unsafe behaviors, primarily by terminating prohibited operations and providing precise semantic feedback.
Figure 7: RQ5: Outcome distribution on 361 OpenAgentSafety tasks. ActPlane prevents 74% of baseline-unsafe outcomes using policies generated from task descriptions.
Theoretical and Practical Implications
ActPlane establishes a new paradigm for programmable, deterministic OS-level policy enforcement in agent harnesses. Hierarchical domains and IFC ensure safety and compliance even with context-dependent, cross-event policies. Semantic feedback facilitates agent recovery, allowing iterative compliance improvements without human intervention. This architecture scales to multi-agent systems, provides robust isolation, and enables runtime adaptation without risk of constraint weakening.
ActPlaneโs approach signals future directions for AI-driven policy synthesis, runtime enforcement in complex environments, and programmatic cross-agent safety assurance. Future work may extend hooks for more granular action tracking, integrate with semantic content linters, and adapt declassification strategies for long-running sessions to mitigate over-tainting.
Conclusion
ActPlane offers deterministic, programmable OS-level enforcement of agent behavioral policies identified as both prevalent and challenging in modern AI agent workflows. Its architecture leverages eBPF and IFC for broad execution path coverage, delivers actionable semantic feedback, and achieves strong compliance and safety outcomes with minimal overhead. The system sets foundational principles for robust, context-adaptive policy enforcement in AI agent harnesses, supporting practical deployment across coding, workflow, and safety-critical domains.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper is about making AI โagentsโ (computer programs that use LLMs to get work done) follow important rules reliably. These rules can be things like โrun the tests before committing codeโ or โdonโt send secret keys to the internet.โ The authors built a system called ActPlane that lets an agent write down these rules in a simple way and then has the computerโs operating system enforce them, so the rules canโt be bypassed by sneaky side effects like scripts or subprocesses.
Think of it like school rules. An agent is a student doing tasks. The โharnessโ is the classroom environment that keeps the student on track. ActPlane is like a hall monitor that watches all hallways, not just the classroom door, and can explain what rule was broken and how to fix it.
What questions did the researchers ask?
They focused on three simple questions:
- Which instructions in real projects are actual rules (what to do or not do) versus just descriptions?
- Which rules need operating system-level checks to enforce (not just reading or writing prompts)?
- How can agents express these rules clearly so a computer can enforce them, even when the rules depend on context (like which project youโre working on) or the order of events (like โbefore you commit, you must have run testsโ)?
How did they approach it?
They used two main approaches: first, a study of real projects to understand the rules people actually write; then, a new system design to enforce those rules.
1) Studying real projects
The team looked at 64 popular GitHub repositories that included instruction files for agents (like โCLAUDE.mdโ or โAGENTS.mdโ). They broke these files into 2,116 individual statements and labeled each as either a rule or just description, and noted what kind of enforcement was needed.
What they found guided the design of ActPlane.
2) Designing ActPlane to enforce rules reliably
To make rules both easy to write and hard to bypass, ActPlane combines three ideas:
- A simple rule language (DSL): The agent writes rules in a clear, almost plain-English style that names actions and conditions, like โBlock โgit commitโ unless tests ran and passed.โ The agent provides project-specific details (like which test command to run).
- Enforcement inside the operating system: ActPlane runs checks in the OS kernel using eBPF (tiny, safe programs that live inside the Linux kernel). Because itโs below the tool layer, it can see everythingโshell commands, scripts, subprocessesโso it canโt be easily dodged.
- Information-flow tracking (IFC): Imagine putting โstickersโ (labels) on processes, files, or data when they come from certain sources (like reading secrets from a .env file). As the data moves (read, write, connect to network), the stickers move with it. If a rule says โdonโt send .env data to the network,โ ActPlane sees the sticker on the network request and blocks it. This also lets it enforce rules that depend on the order of events, like โonly allow committing after tests pass.โ
They also added isolation and safety:
- Policy domains: Think of them as โrule zonesโ for each agent. A parent (like the system or a supervisor) can set strict safety rules. An agent can add more rules for itself or its sub-agents, but cannot weaken or remove inherited rules. This keeps everyone safe while still allowing flexibility.
- Helpful feedback: If ActPlane blocks something, it doesnโt just say โno.โ It says exactly which rule was violated and how to fix it (e.g., โBlocked: committing without tests; run npm test firstโ), so the agent can recover.
What did they find?
From the project study:
- Most statements were rules: About 64% of the statements told the agent what to do or not do.
- Most rules needed system-level visibility: About 83% involved concrete system actions (like running commands, writing files, or making network connections), not just style or wording.
- Many rules depend on context: About 74% needed project or task details (e.g., what command counts as โrun testsโ) and werenโt fully self-contained.
- Some rules depend on event order or data flow: About 16% required tracking โwhat happened whenโ or โwhere did this data goโ (like โrun tests before commitโ or โdonโt let .env data reach the internetโ).
From testing ActPlane:
- Better at catching violations, even hidden ones: Compared to prompt-based filters, simple tool-layer checks, and tool-level information-flow systems, ActPlane fixed 2.0โ3.2 times more rule-breaking cases. It did especially well against โindirect paths,โ like when a script or subprocess performs the risky action.
- Helpful messages matter: When ActPlane explained what went wrong, agents were far more likely to correct and comply.
- Small performance cost: It added about 1.9% extra time on agent workloads and up to 8.4% on very heavy tasks like building the Linux kernelโsmall enough for practical use.
- Safety boost: On a set of assistant tasks, loading sensible safety policies up front allowed ActPlane to prevent about 74% of unsafe behaviors.
Why does this matter?
- More reliable agents: By enforcing rules at the operating system level, agents are less likely to accidentally (or maliciously) do the wrong thing, even if the violation happens in a script or subprocess the agent launched earlier.
- Clearer, fixable errors: Instead of confusing โpermission deniedโ messages, ActPlane tells the agent what rule it broke and how to fix it, improving learning and success rates.
- Scales to real projects: Because many real rules depend on project details and event order, a system that both understands context (via the agentโs rule-writing) and enforces across all execution paths (in the OS) is crucial.
- Safer collaboration: With policy domains, multiple agents can work on the same machine with different rules without interfering, and no one can weaken higher-level safety rules.
In short, ActPlane bridges the gap between the way people write instructions (โRun tests before you commitโ) and the gritty reality of how computers execute actions. It lets agents turn high-level intentions into concrete, enforceable rulesโand it makes sure those rules hold, everywhere, with helpful guidance when they donโt.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a single, concrete list of what remains missing, uncertain, or unexplored, framed so future work can act on it.
- OS and platform scope: Only Linux with eBPF/BPF-LSM is supported/evaluated; feasibility on macOS (DTrace), Windows (ETW/eBPF for Windows), and container orchestrators (Kubernetes, cgroups/namespace boundaries) is unaddressed.
- Hook coverage gaps: Current enforcement covers exec, open, read, write, unlink, connect, fork, exit; missing or unspecified coverage for rename/link/symlink, chmod/chown, mmap, bind/listen/accept/sendmsg/recvmsg (including UDP), Unix domain sockets/pipes/SHM, ptrace/signals, ioctl, FUSE, and DNS may allow policy-relevant actions to evade checks.
- Network-flow fidelity: Enforcement focuses on connect; data exfil over already-established sockets, UDP, local IPC, or protocol-level channels (e.g., DNS tunneling) lacks explicit handling and evaluation.
- Pre- vs post-operation semantics: kill effects are post-operation and may allow partial or irreversible side effects (e.g., writes) before termination; the paper does not specify which operations can be safely blocked pre-op and where residual damage remains.
- File path semantics: Canonicalization and attack surfaces (symlinks, hard links, bind mounts, chroot/mount namespaces, case-insensitive FS, path traversal) are not specified; correctness of path matching under these conditions is unclear.
- Content-based policy gap: 38% of policies require content inspection; ActPlane does not enforce content predicates or integrate with linters/scanners, leaving a large swath of real policies unsupported.
- Cross-session lineage: IFC state is session-scoped; policies that require history across sessions (e.g., โsince last releaseโ or multi-day workflows) are out of scope with no persistence mechanism proposed.
- Distributed/multi-host workflows: Enforcement does not extend across machines, remote runners, CI/CD pipelines, or services; how to coordinate IFC labels and gates in distributed settings is open.
- Label capacity and scalability: Labels are 64-bit bitmasks (โค64 labels); rules are capped at 128; scaling to large policy sets, multi-tenant agents, or fine-grained sources may exceed these limitsโno strategy for label-space multiplexing or hierarchical compression is given.
- Over-tainting and declassification: Monotonic labels can cause over-tainting; suggested mitigation (spawn a fresh subprocess) is ad hoc; a principled declassification/endorsement model, policies for safe label clearing, and guarantees against misuse are not developed.
- Formal guarantees: No formalization or proof of noninterference/soundness of label propagation; no proof of compiler correctness (DSLโeBPF) or authority-checker soundness (i.e., impossibility of weakening inherited constraints by crafty deltas).
- Rule conflict resolution: When multiple rules match with divergent effects (e.g., notify vs block vs kill), precedence, composition, and determinism of outcomes are unspecified.
- Gates and temporal logic limits: Temporal gates (after/since/exits N) cover only a subset of ordering constraints; richer temporal/dataflow logics (e.g., โuntil,โ โexactly-once,โ โwithin T,โ cross-file consistency) are not modeled; runtime updates for more hooks and gates are explicitly deferred.
- Authority checker coverage: The statement that agents โcannot create labels that would satisfy unless gatesโ needs a precise definition and proof; safety against adversarial label algebra or rule encoding to bypass inherited constraints is not demonstrated.
- Feedback safety: Semantic feedback can help recovery but may leak sensitive policy details or operational hints to compromised agents; no guidance on safe redaction/minimizing information leakage is provided.
- Attack surface and evasion: Threat model excludes kernel/CAP_BPF compromise, file contents, and side channels; evasion via setuid helpers, privileged daemons, alternate namespaces, or non-hooked subsystems is not analyzed; DoS risks (map exhaustion, ring-buffer flooding) are not evaluated.
- Namespace and multi-tenant isolation: Interactions with PID/mount/network namespaces and cgroups are not detailed; guarantees that process-tree scoping canโt be escaped (e.g., via reparenting, user namespace tricks) are not established.
- Interaction with existing MAC/LSM: Coexistence and precedence with AppArmor/SELinux/Landlock/Tetragon policies, and how to reconcile conflicting decisions or combine guarantees, are unexplored.
- Policy translation reliability: LLM-based translation correctness beyond a small human-reviewed sample is uncertain; robustness to adversarial or ambiguous instruction files and prompt injection during policy generation is not studied.
- Generalization across agents/models: Effectiveness is shown on specific models (e.g., GPT-5.5, Qwen); behavior across weaker/cheaper open models, non-coding agents, and different harnesses remains untested.
- Evaluation breadth: Overhead and effectiveness are measured on a single host; worst-case stress (high IOPS, many concurrent processes, deep domains, large rule/label sets), long-running sessions, and tail-latency impacts lack comprehensive micro/macro benchmarks.
- LLM-judge validity: End-to-end metrics rely on an LLM trajectory judge with limited human adjudication; inter-judge agreement, robustness, and potential bias are not quantified.
- Policy lifecycle and governance: How policies are versioned, reviewed, signed, audited, and rolled back (especially higher-authority rules) is not specified; supply-chain risks in policy artifacts are unaddressed.
- Developer UX and debugging: Tooling for diagnosing false positives/negatives, visualizing label propagation, and authoring/maintaining complex policies (beyond cost/time estimates) is not evaluated with users.
- Continuous integration and IDE workflows: Integration patterns (pre-commit hooks, CI gates, IDE feedback loops) and their interplay with ActPlaneโs runtime enforcement are not designed or assessed.
- Recovery strategies: Beyond notifying/terminating processes, automated remediation (e.g., suggesting compliant commands, auto-running required tests) and safe rollback of partial side effects are not explored.
- Multi-agent coordination: Policies that span multiple collaborating agents or shared artifacts (e.g., โsub-agent A must wait for Bโs approvalโ) lack a coordination model across domain boundaries.
- Policy expressiveness for exceptions: unless gates are supported, but real-world exception hierarchies (roles, approvals, time-bounded grants) and task-scoped grants (with auditing) are not fully specified or enforced.
- Security of update channel: Kernel ring-bufferโbased delta submission lacks an analysis of integrity, replay, ordering, rate limiting, and backpressure, as well as how denial-of-service is mitigated.
- Reproducibility and portability: The DSL-to-eBPF pipelineโs determinism across kernel versions, verifier differences, and toolchains is not evaluated; portability issues with BPF verifier limits and program complexity are unaddressed.
Practical Applications
Immediate Applications
These use cases can be deployed today on Linux hosts that allow eBPF/BPF-LSM, with integration into agent harnesses or platform tooling.
- Software engineering and DevOps
- Enforce development workflow policies for AI coding agents (e.g., โrun tests before commit,โ โno direct pushes to main,โ โregenerate code after schema changesโ) in IDEs, terminals, and CI/CD.
- Sectors: software, DevOps, open source
- Tools/workflows: VS Code/JetBrains plugins that load ActPlane rules when a coding session starts; Git hooks replaced/augmented by OS-level enforcement; CI runners (GitHub Actions, GitLab CI, Jenkins) that bootstrap higher-authority policies before agent jobs; harness integrations (Claude Code, Codex, OpenHands, AgentOS)
- Assumptions/dependencies: Linux kernel with BPF-LSM; privileged component to load eBPF; agent or pre-run step that resolves โcontext-dependentโ policies (tests, data dirs) into the DSL; acceptance of a 1.9โ8.4% overhead on targeted workloads; operational tuning to minimize false positives
- Block high-risk file and system actions by agents with concrete recovery guidance (e.g., โdo not delete data directories,โ โdo not write outside project,โ โno npm publish on feature branchesโ).
- Sectors: software, enterprise IT
- Tools/workflows: harness-level shell/file tool wrappers augmented by kernel enforcement; policy packs per language (Node, Go, Python) and per VCS workflow
- Assumptions/dependencies: explicit path patterns or resolved project layout; userspace feedback channel wired into the agent loop
- Enterprise data loss prevention (DLP) for AI agents
- Prevent secret and sensitive data exfiltration by tracking lineage from sources like .env, keyrings, or mounted secrets to network sinks; allow safe destinations while blocking others with explanations.
- Sectors: enterprise IT/security, finance, healthcare
- Tools/products: โAgent DLPโ service that loads a corporate baseline of higher-authority rules before any agent starts; SIEM/SOAR integration consuming ActPlaneโs semantic feedback and violation logs
- Assumptions/dependencies: accurate identification of sensitive file locations and approved endpoints; policy domain hierarchy for multi-tenant/user isolation; alignment with corporate change-control processes
- Safe production automation and SRE co-pilots
- Enforce change checklists and gated workflows for agents operating infra (e.g., โapply Terraform only after plan approved,โ โrestart only within maintenance window,โ โno prod writes from non-release branchesโ).
- Sectors: cloud, SaaS, SRE/AIOps
- Tools/workflows: Kubernetes node-level DaemonSet that injects ActPlane policy for agent pods; per-pod policy domains; integration with approval systems for โunless approvedโ task gates
- Assumptions/dependencies: privileged eBPF in containers or host; clear mapping from business approvals to task-scoped labels; compatibility with managed Kubernetes policies
- Safer hosted IDEs and cloud sandboxes
- Offer multi-tenant, OS-enforced guardrails with human-readable feedback in cloud coding environments (e.g., Codespaces, internal sandboxes), preventing cross-tenant effects and unsafe network/file actions.
- Sectors: cloud/SaaS, education
- Tools/products: pre-baked policy images; per-tenant domain trees; โpolicy-as-a-serviceโ APIs
- Assumptions/dependencies: provider support for eBPF; scalable per-session domain management; process-tree containment
- AI agent governance for regulated workflows
- Encode โrun KYC/AML checks before trade placementโ or โde-identify before exporting PHIโ as cross-event rules attached to agent process trees; block or guide actions with auditability.
- Sectors: finance, healthcare
- Tools/workflows: higher-authority policy packs aligned to SOX/PCI/HIPAA; audit trails from ActPlane events into GRC systems
- Assumptions/dependencies: mapping domain-specific validations to concrete commands/data sources; regulator acceptance of OS-level IFC logs as evidence; careful performance sizing for latency-sensitive actions
- Safer personal assistants on developer laptops
- Prevent destructive or privacy-violating actions by local assistants (e.g., โdonโt rm -rf in ~,โ โdonโt send clipboard or keychain data to the internet,โ โno package installs without confirmationโ).
- Sectors: daily life, prosumer IT
- Tools/workflows: lightweight tray app or CLI that loads baseline rules before assistant sessions; optional per-task self-restrictions authored by the agent
- Assumptions/dependencies: Linux desktop or WSL; user consent to privileged loader; curated defaults to avoid usability friction
- Research and teaching testbeds
- Use ActPlane as a reproducible platform for studying agent-policy generation, OS-level IFC, and human-in-the-loop recovery; build new benchmarks on indirect execution paths and cross-event constraints.
- Sectors: academia, education
- Tools/workflows: course labs demonstrating IFC; replication of the paperโs DSL-generation pipeline; open-source benchmark suites
- Assumptions/dependencies: Linux lab infra; instructor familiarity with eBPF/IFC concepts
- Open-source project policy packs
- Maintain CLAUDE.md/AGENTS.md as source-of-truth and auto-translate to ActPlane rules for contributors and bots (e.g., standard โtests-before-commitโ packs for common frameworks).
- Sectors: open source, software
- Tools/workflows: CI step that regenerates and validates rule sets; repo templates per ecosystem
- Assumptions/dependencies: community adoption; reliable policy translation agents for project context
Long-Term Applications
These require additional engineering, ecosystem adoption, scaling, or standardization beyond the current Linux/eBPF implementation.
- Cross-platform OS enforcement for agents
- Windows/macOS equivalents to enforce agent-written policies at kernel or hypervisor level with semantic feedback.
- Sectors: enterprise IT, consumer
- Dependencies: OS vendor hooks (e.g., ETW/Mac audit), driver signing policies, alternative to eBPF, security review/certification
- Cluster- and service-meshโwide information flow control
- Propagate labels across hosts and microservices (processโcontainerโservice) to enforce end-to-end โno secret-to-internetโ and workflow-ordering policies across distributed systems.
- Sectors: cloud/SaaS, fintech, healthtech
- Dependencies: sidecar/mesh integration, cross-host provenance protocols, scalable label semantics, compatibility with zero-trust architectures
- Certified governance for high-assurance domains
- Formal verification of the DSL-to-eBPF compiler and selected rules, along with audit-grade logging/attestation, to meet safety and regulatory certifications (DO-178C, IEC 61508, HIPAA, PCI).
- Sectors: aviation/robotics, healthcare, finance, energy
- Dependencies: verified BPF frameworks, policy provenance/attestation (e.g., with TEEs), regulator engagement
- Rich content- and AST-aware enforcement
- Combine OS-level IFC with linters/AST diff watchers so rules can say โif API schema file changed and tests for affected endpoints didnโt run, block release.โ
- Sectors: software, API platforms
- Dependencies: deterministic content analyzers wired into gates; performance budgets for content checks; extended hooks beyond current events
- Automated policy synthesis and continuous adaptation
- Agents derive and maintain rules from repo structure, CI configs, and organizational policies; learn from violation feedback to refine scopes automatically.
- Sectors: enterprise IT, open source
- Dependencies: robust LLM-to-DSL pipelines; guardrails that prevent weakening inherited constraints; human-in-the-loop review
- Industry standards for agent OS governance
- Standardize a portable policy DSL and enforcement model for agent harnesses, aligning with NIST/NCSC guidance and cloud best practices; certification programs for โagent-safeโ platforms.
- Sectors: policy, cloud/SaaS
- Dependencies: cross-vendor consensus, open specs, conformance test suites, reference implementations
- Robotics and industrial automation safety gates
- Enforce multi-step safety sequences for agent-driven robots/IIoT (e.g., โstop before tool change,โ โlockout completed before actuator enableโ), with lineage from sensor data to actuation.
- Sectors: robotics, manufacturing, energy
- Dependencies: real-time constraints, embedded Linux/eBPF availability, functional safety validation, integration with PLCs/fieldbuses
- Mobile/edge device agent controls
- Lightweight kernel/user-space enforcement on edge devices to prevent data leakage and enforce on-device-only processing unless specific gates are met.
- Sectors: IoT, consumer electronics
- Dependencies: kernel support on constrained devices, power/perf budgets, OEM cooperation
- End-to-end attestation and insurance-grade auditability
- Bind agent policy domains to cryptographic attestations (e.g., TPM/TEE) for provable controls; offer cyber insurance discounts for compliant deployments.
- Sectors: insurance, enterprise risk
- Dependencies: attestation infrastructure, insurer risk models, tamper-evident logs
- User-facing governance dashboards
- Productize a โpolicy cockpitโ for security and platform teams to author higher-authority rules, see violations with semantic context, and approve declassification requests.
- Sectors: enterprise IT/security
- Dependencies: RBAC, change-management integration, usability research to avoid alert fatigue
- Supply-chain and release-security enforcement
- Enforce โonly signed tools can run,โ โSBOM must be updated before release,โ โno network during build,โ tracked across build stages and workers.
- Sectors: software, embedded systems
- Dependencies: integration with signing/SBOM tooling, cross-worker label propagation, reproducible build systems
Cross-cutting assumptions and limits to keep in mind
- Platform prerequisites: Linux with BPF-LSM enabled and a privileged loader (or trusted sidecar) are required; containers often need elevated permissions or host-level deployment.
- Coverage boundaries: Enforcement observes OS-visible events (exec/open/write/connect/etc.); content-only semantics and covert/side channels are out of scope without additional tooling.
- Context resolution: Most real policies need project/task context; accuracy of LLM-generated DSL and repository understanding directly impacts precision/recall.
- Isolation model: Policy domains prevent weakening inherited constraints but require careful scoping to avoid over-tainting; long sessions may need declassification workflows.
- Performance and scale: The reported overhead (โ2% typical, up to โ8%) is acceptable for many dev/ops tasks but must be measured for latency-sensitive or high-throughput systems.
- Maturity gaps: Some extended hooks/temporal gates and runtime update paths are future work; cross-OS support and formal verification are long-term efforts.
Glossary
- AI agent harness: The software layer around an LLM that manages tools, state, and I/O for agents. Example: "Agents operate through an AI agent harness: software around the model that maintains the agent loop and session state, routes tool calls, mediates shell, file, and network access, and returns results or feedback to the model, improving agent performance while enforcing instructions and constraints"
- AppArmor: A Linux security module providing mandatory access control for processes and files. Example: "At the OS level, mechanisms such as seccomp~\cite{seccomp-bpf}, AppArmor~\cite{apparmor}, Landlock~\cite{landlock}, and Tetragon~\cite{ciliumtetragon} restrict process, file, and network access below the tool layer and are increasingly adopted as agent sandboxes, but they control resource access instead of actions, expect statically pre-written policies, and return opaque errors that confuse the agent."
- authority checker: A kernel-resident component that validates and enforces constraints on runtime policy updates so lower-authority rules cannot weaken inherited ones. Example: "ActPlane requires an authority checker that runs entirely in the kernel."
- BPF-LSM: The eBPF attachment mechanism to Linux Security Module hooks for pre-operation security enforcement. Example: "via BPF-LSM for pre-operation enforcement (block effects) and tracepoints for observation and post-operation termination (kill effects)."
- BPF map: A kernel keyโvalue store used by eBPF programs to keep state such as labels. Example: "Label state is stored as 64-bit bitmasks in per-object BPF maps"
- CAP_BPF: A Linux capability controlling privileged eBPF operations such as program loading. Example: "File contents, kernel compromise, CAP_BPF compromise, and side channels are out of scope."
- Capsicum: A capability-based security framework (notably in FreeBSD) for sandboxing processes. Example: "The agent may then author additional rules at runtime, following the self-restriction principle of Landlock~\cite{landlock} and Capsicum~\cite{watson2010capsicum}."
- declassification: The controlled removal or downgrading of information-flow labels to relax restrictions under policy. Example: "As in Flume~\cite{flume} and HiStar~\cite{zeldovich2006histar}, labels are irrevocable by default, and declassification (controlled label removal) is delegated to the domain hierarchy (\S\ref{sec:authority})."
- declassify/endorse transforms: Operations in IFC systems to downgrade (declassify) or upgrade (endorse) information security levels. Example: "Only declassify/endorse transforms are unused, as expected, because they address over-tainting in long-running sessions, a scenario absent from this task-oriented dataset."
- Domain-specific language (DSL): A specialized language tailored to expressing policies at a higher level than code. Example: "ActPlane uses a simple information-flow control (IFC) DSL to support cross-event policies."
- domain hierarchy: A tree of policy domains with inheritance and isolation between process subtrees. Example: "ActPlane introduces policy domains, organized into a domain hierarchy."
- eBPF: Extended Berkeley Packet Filter; a programmable, in-kernel virtual machine for safe, dynamic instrumentation and enforcement. Example: "We implement ActPlane with eBPF and evaluate it on policies from the empirical study, coding-task benchmarks, and safety benchmarks."
- EPERM: A POSIX error code indicating an operation is not permitted. Example: "returning opaque denials (e.g., EPERM) without explaining which policy was violated or how to comply."
- FIDES: A tool-level information-flow control framework for agent tool calls. Example: "FIDES~\cite{costa2025fides} (tool-level IFC)"
- Flume: An operating-system IFC system that enforces label-based information flow with capabilities. Example: "As in Flume~\cite{flume} and HiStar~\cite{zeldovich2006histar}, labels are irrevocable by default"
- HiStar: A research operating system enforcing information-flow policies via labels and isolation. Example: "As in Flume~\cite{flume} and HiStar~\cite{zeldovich2006histar}, labels are irrevocable by default"
- information-flow control (IFC): A security model that tracks and restricts how information propagates between subjects and objects using labels. Example: "Information-flow control (IFC) tracks how data moves from sources to sinks by attaching labels to OS objects and propagating them at runtime"
- Landlock: A Linux security module enabling unprivileged, self-imposed sandboxing of processes. Example: "At the OS level, mechanisms such as seccomp~\cite{seccomp-bpf}, AppArmor~\cite{apparmor}, Landlock~\cite{landlock}, and Tetragon~\cite{ciliumtetragon} restrict process, file, and network access"
- lineage gate: A policy predicate that requires a process to descend from a particular ancestor. Example: "A lineage gate checks whether the subject descends from a particular process"
- monotonic labels: Labels that only accumulate (are never removed) to preserve conservative tracking of prior influences. Example: "labels are monotonic: propagation adds labels but never removes them"
- over-tainting: An IFC situation where too many labels accumulate, causing excessive restriction of actions. Example: "objects become overly restricted (over-tainting); spawning a fresh subprocess clears inherited labels, providing a practical mitigation."
- policy domain: An isolated scope in which a process subtreeโs policies apply, with inheritance from parent domains. Example: "ActPlane introduces policy domains"
- policy engine: A component that interprets and enforces policies over an agentโs actions. Example: "A major component of the harness is a policy engine, which observes and enforces instructions and constraints"
- prompt injection: An adversarial technique that manipulates an LLM via crafted inputs to subvert intended behavior. Example: "Above the OS, prompt instructions rely on the model's own compliance capabilities~\cite{liu2024lost,jiang2024followbench,qi2025agentif} but are vulnerable to prompt injection~\cite{greshake2023indirectprompt,zhan2024injecagent,debenedetti2024agentdojo}."
- ring buffer: A circular buffer used for efficient, lock-free communication between kernel and userspace. Example: "Agents submit precompiled deltas through a userspace ring buffer"
- scheduler tracepoint: A kernel trace event hook on the scheduler used to observe task state like exit codes. Example: "A scheduler tracepoint reads the task exit code to arm exit-qualified gates only on normal termination with the specified status."
- seccomp: A Linux facility to filter and restrict syscalls made by a process. Example: "At the OS level, mechanisms such as seccomp~\cite{seccomp-bpf}, AppArmor~\cite{apparmor}, Landlock~\cite{landlock}, and Tetragon~\cite{ciliumtetragon} restrict process, file, and network access"
- temporal gate: A policy predicate that enforces ordering between events (e.g., after/since conditions). Example: "a temporal gate uses after~...~since~... to enforce ordering."
- TCB (Trusted Computing Base): The set of components whose correct operation is critical to system security guarantees. Example: "The trusted computing base (TCB) comprises the kernel enforcement engine and higher-authority policy"
- Tetragon: An eBPF-based runtime security observability and policy enforcement tool. Example: "At the OS level, mechanisms such as seccomp~\cite{seccomp-bpf}, AppArmor~\cite{apparmor}, Landlock~\cite{landlock}, and Tetragon~\cite{ciliumtetragon} restrict process, file, and network access"
- TOCTOU: Time-of-check to time-of-use; a race where state changes between a check and the subsequent use. Example: "block offers a recoverable alternative by synchronously denying the syscall pre-operation (leaving no TOCTOU gap)"
- tool-call guardrails: Deterministic checks at the tool invocation boundary that approve or block tool uses. Example: "Tool-call guardrails miss system actions that bypass the tool layer, such as a git~commit inside a script the agent wrote earlier."
- tracepoint: A static kernel instrumentation hook used to observe events like syscalls or scheduling. Example: "and tracepoints for observation and post-operation termination (kill effects)."
Collections
Sign up for free to add this paper to one or more collections.
