Meet Prempti: Unleashing AI Coding Agents with Policy and Visibility

AI-powered coding assistants have become a genuine part of how developers work today. Tools like Claude Code operate right inside your terminal — reading files, executing shell commands, making network requests, and writing code, all on your behalf. They’re quick, powerful, and increasingly relied upon for real work on real machines.

But that trust raises an important question: what is your coding agent actually doing on your system?

On May 12th, the Falco team unveiled Prempti, a new experimental addition to the Falco ecosystem. Falco — a CNCF graduated project and the industry standard for cloud-native runtime security — has long provided policy-driven threat detection for containers, Kubernetes, and host systems. Prempti brings that same approach to a brand-new domain: the AI agent tool-call lifecycle.

Agents operate as a black box during execution

When a coding agent executes a bash command, modifies a file, or reads a configuration, those actions take place within your user session, using your permissions, on your filesystem, with your credentials. Most developers using these tools have no organized way to observe that activity. You see the agent’s chat responses, but you have no insight into what’s happening behind the scenes.

Consider this straightforward example: you ask your coding agent to refactor a module. It reads your source files, makes changes, and then — perhaps triggered by a malicious dependency or an unexpected instruction in a file it just processed — it tries to read ~/.ssh/known_hosts or write a file to ~/.aws/. Should it be permitted to do that? Would you even be aware if it attempted it?

The demo on the Falco blog illustrates this exact scenario. The agent attempted to both read and write to areas it shouldn’t have access to, and both attempts were blocked. The agent itself received a clear, structured message explaining the reason. This is detection and guardrails working in tandem at the tool-call level.

How Prempti works

Prempti operates as a lightweight user-space service that runs alongside your coding agent. It doesn’t need root access, kernel modules, or containers. Whenever your agent makes a tool call — whether it’s a file write, a shell command, or a file read — Prempti intercepts it before execution, checks it against Falco rules, and returns a verdict:

The architecture works as follows:

1. Prempti’s hook triggers before each tool call
2. An interceptor forwards the event to Falco through a Unix socket
3. Falco’s rule engine evaluates the event against your defined policies
4. Matching rules generate verdicts (deny / ask / allow)
5. The interceptor passes the verdict back to the agent

Prempti leverages Falco’s plugin system to define a new event source called coding_agent, with fields tailored for this use case: tool.name, tool.input_command, tool.file_path, agent.cwd, and more. If you’ve ever written Falco rules before, the policy format will feel immediately familiar.

Two modes: Monitor and Guardrails

Monitor mode evaluates every tool call against your rules and records the results, but doesn’t enforce any action. This is the recommended way to get started: run it for a few sessions, observe what your agent actually accesses, and fine-tune your rules before turning on enforcement.

Guardrails mode (the default) fully enforces all verdicts — deny blocks the action, ask prompts you for a decision, and allow lets it proceed.

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

Rules: familiar Falco YAML, new context

Here’s a rule that blocks piping content directly into a shell interpreter — a well-known 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 designed to be LLM-friendly, so the agent receives it as a structured message it can present directly to you. Correlation IDs let you trace every event across your logs.

The default ruleset covers six key areas:

• Working-directory boundary — monitor and prompt on file access outside the session’s project directory
• Sensitive paths — deny reads and writes to /etc/, ~/.ssh/, ~/.aws/, cloud credential files, .env files, and similar locations
• Sandbox disable — detect attempts to disable the agent’s own sandbox configuration
• Threats — credential access, destructive commands, pipe-to-shell patterns, encoded payloads, data 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 environment files

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

Honest about limitations

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

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

Getting started

Download the latest release from GitHub:

Full technical walkthrough and architecture details:

Get involved

Runtime security for AI coding agents is uncharted territory. The threat models are still being mapped out, and the right default policies are still being refined. If you give Prempti a try, we’d love to hear about your experience:

• What rules have you written? What did you catch?
• What agents or platforms do you need support for?
• What didn’t work the way you expected?

Open an issue, start a discussion, or find us in the Falco channel on CNCF Slack. Every piece of feedback helps shape 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.