[Feature]: OS-Level Enforcement in AI Agent Governance

[rastogivaibhav]

Package

agent-os-kernel

Problem Statement

Modern AI agents are rapidly evolving from passive assistants into autonomous systems capable of executing workflows, invoking tools, accessing APIs, modifying infrastructure, interacting with enterprise data, and orchestrating cross-system operations.

Current governance frameworks, including application-layer agent governance toolkits, primarily operate within the same trust boundary as the agent runtime itself. While these frameworks provide valuable policy orchestration, telemetry, and middleware controls, they remain fundamentally dependent on the integrity of the userspace process executing the agent.

This creates a structural security gap.

⸻

Core Problem

Application-layer governance can be bypassed when:

• The agent runtime is compromised through prompt injection
• A malicious or compromised plugin executes unauthorized operations
• A process hijack occurs within the same userspace boundary
• Middleware hooks are disabled or circumvented
• Network egress occurs outside the monitored execution path
• Local execution environments bypass framework-native interception

As AI agents become increasingly autonomous and capable of interacting with sensitive systems, enterprises require a non-bypassable enforcement layer capable of operating independently from the agent runtime itself.

Today, there is no standardized OS-level enforcement model integrated into mainstream AI governance stacks.

⸻

Why This Matters

Enterprise AI governance currently lacks:

• Kernel-level policy enforcement
• Non-bypassable execution controls
• OS-native network interception for AI agents
• Tamper-resistant runtime enforcement
• Independent trust boundaries outside userspace
• Cryptographically verifiable forensic execution trails

This creates operational and compliance risks for enterprises deploying autonomous AI systems into production environments.

⸻

Proposed Solution

Proposed Direction

Introduce support for OS-level governance enforcement as a complementary enforcement layer alongside Microsoft Agent Governance Toolkit (AGT).

The proposed model would enable:

• Policy enforcement below the application trust boundary
• Runtime interception of outbound actions before execution
• Independent enforcement even if the agent process is compromised
• Fail-closed enforcement behavior
• Cryptographically verifiable audit chains
• Defense-in-depth between middleware governance and operating system controls

Potential integration points may include:

• Windows Filtering Platform (WFP)
• Event Tracing for Windows (ETW)
• eBPF-based enforcement for Linux environments
• Kernel telemetry hooks
• External policy decision points (OPA/Rego)
• Enterprise SIEM and compliance systems

⸻

Strategic Value

This capability would help establish:

• A trusted runtime model for autonomous AI systems
• Stronger enterprise adoption confidence
• Improved compliance alignment (EU AI Act, NIST AI RMF, ISO 42001)
• Reduced risk of agentic abuse and unauthorized execution
• Defense-in-depth architecture for production AI systems

⸻

Desired Outcome

A future AI governance architecture where:

• Application-layer governance provides orchestration and developer ergonomics
• OS-level enforcement provides non-bypassable runtime guarantees
• Enterprises can securely deploy autonomous AI agents into production environments with verifiable enforcement and forensic traceability

In this model, governance moves from being advisory middleware to enforceable runtime security infrastructure.

Alternatives Considered

No response

Priority

None

Contribution

• I would be willing to submit a PR for this feature

[github-actions]

Welcome to the Agent Governance Toolkit! Thanks for opening your first issue.
A maintainer will review this shortly. Check our Contributing Guide.
For security issues, use private vulnerability reporting.

[github-actions]

🤖 AI Agent: contributor-guide

Hi there, welcome to the community! 👋 Your feature request for OS-level enforcement in the agent-os-kernel package is highly insightful and aligns with enterprise security needs. To get started with contributing, please review our CONTRIBUTING.md for guidelines. Excited to see your ideas take shape! 🚀

[Ricky-G]

@rastogivaibhav Thanks for the detailed write-up, the threat model is real and worth taking seriously. I want to push back on the shape of the solution, though, because I think there's a stronger framing that delivers most of what you're asking for without AGT taking on responsibilities it shouldn't own.

Reframing: AGT as event producer, not kernel enforcer

The proposal asks AGT to become an OS-level enforcer (eBPF programs, WFP callouts, kernel telemetry hooks). I'd argue that's the wrong layer for this project to own:

• Don't compete with Defender / Sentinel / Falco / Tetragon. They have 10+ years of EDR/SIEM engineering, driver signing infrastructure, and kernel ABI tracking behind them. AGT can't match that and shouldn't try.
• Meet customers where they already are. Every enterprise already runs a SIEM/XDR. They want one more source, not one more console.
• The Defender for DevOps analogy is exact. GHAS/ADO emit findings; Defender ingests them. AGT should emit governance events; Defender / Sentinel / Splunk / Falco ingest them. Same shape, proven pattern.

The thin slice that delivers ~70% of your threat model

Instead of a kernel package, AGT should expose a provider interface (SPI / pluggable backend — same pattern AGT already uses for sandboxing) for governance events:

1. IGovernanceEventSink — one async method, takes a structured event. Mirrors the existing sandbox provider shape for consistency.
2. Canonical event schema — OpenTelemetry semantic conventions + CloudEvents envelope, signed. Categories: policy.decision, policy.breach, identity.assertion, tool.invocation, sandbox.event, audit.chain.
3. Two reference sinks: OtlpEventSink (covers Defender, Sentinel, Splunk, Datadog, Honeycomb, Dynatrace — they all ingest OTLP) and StdoutEventSink (dev/CI).

How this maps to your original asks

Your ask	Outcome under this model
Cryptographically verifiable audit chain	✅ Signed event envelopes, native
External enforcement / visibility	✅ Falco / Tetragon / Defender become sinks; their reactions can feed back as policy
Bypass-resistant telemetry	⚠️ Still in-process — but a SIEM that expects events and sees silence treats silence as a signal. This is how EDR works today.
AGT ships eBPF / WFP / kernel drivers	❌ wrong layer, wrong project

Why this scales better

You don't write the Splunk integration. The Splunk team — or the community — does, against a stable interface. Same for Sentinel, Datadog, Falco, etc. AGT stays focused on agent governance; the ecosystem handles distribution into enforcement/observability backends.

I'm going to open a separate issue scoped to this provider-interface slice so it can be discussed on its own merits without conflating it with the kernel-enforcement proposal here.

Will link it back here and for that issue more than happpy for you to contirbute to the design, first we would need to do a high level design and have the AGT team review and we can create tickets to build that out.

[Ricky-G]

Raised this issue to track the IGovernanceEventSink

#1999