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:
| Verdict | What Happens |
| Allow | The tool call proceeds normally |
| Deny | The tool call is blocked and the agent is told why |
| Ask | You are prompted to approve or reject interactively |
The architecture:
- Prempti’s hook fires before each tool call
- An interceptor sends the event to Falco via a Unix socket
- Falco’s rule engine evaluates the event against your policies
- Matching rules produce verdicts (deny / ask / allow)
- 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:
- Working-directory boundary — monitor and ask on file access outside the session’s project directory
- Sensitive paths — deny reads and writes to /etc/, ~/.ssh/, ~/.aws/, cloud credentials, .env files, and similar
- Sandbox disable — detect attempts to disable the agent’s own sandbox configuration
- Threats — credential access, destructive commands, pipe-to-shell, encoded payloads, exfiltration, IMDS access, reverse shells, and supply-chain installs from known-malicious hosts
- MCP and skill content — MCP server config poisoning and slash-command file injection
- Persistence vectors — hook injection, git hooks, package-registry redirects, AI API base-URL overrides, and API keys leaking into env files
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:
- What rules have you written? What did you catch?
- What agents or platforms do you need support for?
- What didn’t work as expected?
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.