AI coding agents have become a real part of the developer workflow. Tools like Claude Code sit in your terminal, read your files, run shell commands, make network requests, and write code, all on your behalf. They are fast, capable, and increasingly trusted with real tasks on real machines.

But with that trust comes a question worth taking seriously: what exactly is your coding agent doing on your machine?

On May 12th, the Falco team introduced Prempti, a new experimental project in the Falco ecosystem. Falco, a CNCF graduated project and the de facto standard for cloud native runtime security, has long brought policy-driven detection to containers, Kubernetes, and hosts. Prempti extends that same model to a new surface: the AI agent tool-call lifecycle.

Agents are a black box at runtime

When a coding agent runs a bash command, writes a file, or reads a configuration, those actions happen inside your user session, with your permissions, in your filesystem, against your credentials. Most developers using these tools have no structured visibility into that activity. You see the agent’s chat output, but you don’t see what’s happening under the hood.

Here’s a simple scenario: you ask your coding agent to refactor a module. It reads your source files. It makes edits. Then, perhaps prompted by a malicious dependency or an unexpected instruction in a file it just parsed, it attempts to read ~/.ssh/known_hosts or write a file to ~/.aws/. Should it be allowed to? Would you even know if it tried?

The demo on the Falco blog captures this situation. The agent tried to both read and write to sections it’s not allowed to, and both were blocked. The agent itself received a structured message explaining why. This is detection and guardrail working together at the tool-call level.

How Prempti works

Prempti runs as a lightweight user-space service alongside your coding agent. It does not require root, kernel modules, or containers. When your agent makes a tool call – a file write, a shell command, a file read – Prempti intercepts it before it executes, evaluates it against Falco rules, and delivers a verdict:

VerdictWhat Happens
AllowThe tool call proceeds normally
DenyThe tool call is blocked and the agent is told why
AskYou are prompted to approve or reject interactively

The architecture:

  1. Prempti’s hook fires before each tool call
  2. An interceptor sends the event to Falco via a Unix socket
  3. Falco’s rule engine evaluates the event against your policies
  4. Matching rules produce verdicts (deny / ask / allow)
  5. The interceptor delivers the verdict back to the agent

Prempti uses Falco’s plugin system to define a new event source (coding_agent) with fields purpose-built for this context: tool.name, tool.input_command, tool.file_path, agent.cwd, and so on. If you’ve written Falco rules before, policies will feel immediately familiar.

Two modes: Monitor and Guardrails

Monitor mode evaluates every tool call against your rules and logs the results, but does not enforce any action. This is the recommended starting point: run it for a few sessions, see what your agent actually touches, and tune your rules before enabling blocking.

Guardrails mode (the default) fully enforces verdicts — deny blocks, ask prompts you, allow proceeds.

premptictl mode monitor      # observe only
premptictl mode guardrails   # enforce verdicts
premptictl logs -f           # watch live events

Rules: familiar Falco YAML, new context

Here’s a rule that blocks piping content directly to a shell interpreter, a classic vector for prompt injection attacks:

- macro: is_bash
    condition: tool.name = "Bash"

  - macro: is_pipe_to_shell
    condition: >
     tool.input_command contains "| bash"
     or tool.input_command contains "|bash"
     or tool.input_command contains "| sh"
     or tool.input_command contains "|sh"
     or tool.input_command contains "| zsh"
     or tool.input_command contains "|zsh"
     or tool.input_command contains "bash <("
 

  - rule: Deny pipe to shell interpreter
    desc: >
      Blocks Bash commands that pipe network-fetched or generated content directly
      into a shell interpreter. Covers curl|bash, wget|sh, bash <(...), and
      similar patterns used for remote code execution and supply chain attacks.
    condition: is_bash and is_pipe_to_shell
    output: >
      Falco blocked piping content to a shell interpreter (%tool.input_command)
    priority: CRITICAL
    source: coding_agent
    tags: [coding_agent_deny]

The output field is LLM-friendly, so the agent receives it as a structured message it can surface directly to the user. Correlation IDs allow you to trace every event across your logs.

The default ruleset covers six areas:

Custom rules go in ~/.prempti/rules/user/ and are preserved across upgrades.

Honest about limitations

Prempti intercepts tool calls as declared by the agent, not the system calls those tool calls produce. If an agent writes a malicious binary and runs it, Falco sees gcc main.c -o main and ./main, not what ./main does at the OS level. For deep syscall-level visibility on Linux, Falco’s kernel instrumentation (eBPF/kmod) remains the right tool.

Prempti is not a sandbox. Think of it as a policy layer at the agent level — a complement to sandboxing and system hardening, not a replacement for them.

Getting started

Download the latest release from GitHub: https://github.com/falcosecurity/prempti/releases

Full technical walkthrough and architecture detail: https://falco.org/blog/introducing-prempti

Get involved

Runtime security for AI coding agents is new territory. The threat models are still being defined and the right default policies are still being worked out. If you try Prempti, we’d love to hear what you found:

Open an issue, start a discussion, or find us in the Falco channel on CNCF Slack. Every piece of feedback shapes where this project goes next.

Prempti is released under the Apache License 2.0. Currently supports Claude Code on Linux (x86_64, aarch64), macOS (Apple Silicon, Intel), and Windows (x86_64, ARM64). Codex integration is planned.