AI Permission: From Session Layer to Kernel Layer

AI Guardian / KAIL tackles an important and timely problem: autonomous AI agents with live credentials can cause irreversible damage faster than humans can react, and session-layer controls are fundamentally bypassable because they operate in the same context as the agent. The three exploits against Claude Code's auto mode (using `psycopg2`, `urllib` with a sub-agent, and `rm` via a fresh sub-agent) convincingly demonstrate that the weakness is architectural rather than a missing rule. The Layer 1–5 model, hardware-wallet analogy, and eBPF-based implementation provide a practical and well-executed defense.

A few improvements would strengthen the paper. First, broaden the evaluation beyond the three exploits by testing additional database drivers, HTTP clients, and deeper sub-agent chains to show the bypasses generalize. Second, include performance metrics such as latency, false positives, and the impact of freezing processes during active operations. Finally, demonstrating protection against a realistic end-to-end attack, such as the PocketOS-style database wipe scenario, would provide even stronger validation.

Overall, this is a well-written and compelling paper that makes a meaningful contribution to AI agent security.

A genuinely strong project — real working system, sound threat model, and an approach that addresses a real gap. Unlike many submissions this one actually does what it claims. Main issues:

Document/landing-page contradictions undercut trust. The README says Email Guardian is live and tested; the landing page marks it "PLANNED." The landing page reports "0 Total Intercepts (24h)" yet "100% eBPF Catch Rate" and a live intercept feed — those don't cohere. Pick one source of truth and make the claims consistent.

"100% catch rate" with 0 intercepts and 3 hand-built bypass cases isn't a measured result. It's three anecdotes you constructed, not an evaluation. Run a real suite — N destructive operations across varied vectors (drivers, sub-agents, compiled binaries, shells) — and report catch rate with the denominator. That converts the claim from marketing to evidence.

The threat model has an unaddressed hole. You note a compromised agent can't bypass by killing the guardian (needs root). But the agent runs as uid=1000 and the guardian's own allow rules exempt /tmp/ and ~/.claude/ for claude-code — a rogue agent operating within those paths, or using a syscall you don't hook (e.g. rename/renameat2 to clobber a file rather than unlink, or truncate), evades silently. Enumerate the syscall coverage gaps explicitly.

Live, publicly-reachable infrastructure is a real risk. A root-running eBPF service with a dashboard bound to 0.0.0.0:8080 and a public EC2 hostname in the submission is an exposure liability, not a feature. Note auth/binding posture.

Telegram-in-the-loop has a latency/availability failure mode — 1800s auto-deny is a long freeze, and a network/bot outage stalls every destructive op. Discuss degradation behavior.

This is a compelling and practically important project. The paper identifies a real operational safety gap for AI agents: application/session-layer permission systems can be bypassed by direct library calls, fresh sub-agents, or background processes, while the destructive operation still ultimately reaches the kernel or network stack. The “Kernel-Level AI Isolation Layer” framing is clear, and the AI Guardian prototype makes the argument concrete.

The strongest contribution is the end-to-end demonstration: three bypasses against session-layer controls, followed by a kernel/eBPF implementation that intercepts the same classes of destructive operations. The layer-by-layer permission-stack analysis is also useful because it explains why adding more deny rules is unlikely to be sufficient. The human-in-the-loop approval workflow and audit trail are practical design choices for production agent deployments.

The main improvement would be to strengthen the empirical and reproducibility details. The paper would benefit from clearer experimental logs, exact environment setup, code availability, and quantitative measurements: interception latency, false-positive/false-negative rates, overhead under normal workloads, approval timeout behavior, and how often legitimate operations are blocked. The incident examples are motivating, but some citations appear informal or difficult to verify; stronger sourcing or clearer caveats would improve credibility.

The security model should also be sharpened. Kernel-level enforcement is powerful, but it introduces its own trusted computing base, operational risks, and bypass possibilities: non-OpenSSL TLS stacks, encrypted payloads before the hook point, root-level tampering, process-freeze denial of service, and broad pattern-matching false positives. The paper acknowledges several of these, but the claims that KAIL “catches all” or reduces the surface to a few hook points should be softened unless broader coverage is demonstrated.

Overall, this is a high-impact systems safety prototype with a strong practical thesis. It would be especially valuable with more rigorous benchmarking, broader API coverage, and a clearer comparison to existing endpoint detection/response, policy engines, and sandboxing approaches.