Introduction
Overview
Fencio is a control point for coding agents. It intercepts the steps an agent takes, evaluates each one against your rules, and answers one question before the step runs: is this action allowed?
The agent action gap
Traditional security controls were built to judge a request. A coding agent does not send one request; it pursues a goal through a chain of steps, and a harmless-looking step can carry a harmful effect. The request can pass every check while the action it enables is the one that matters.
The gap is not about the prompt or the payload. It is about impact: what data moves, what state changes, and what runs.
How Fencio solves it
Fencio evaluates each intercepted step the way an engineer would, by its content, its context, and its intended impact, then returns one decision.
- **Content**: what is being exchanged, such as prompts, responses and files.
- **Context**: which scenario this is, including the workflow, the environment, and what happened earlier in the session.
- **Intent to impact**: what the action may change, such as what data moves, what resource state changes, and what runs at runtime.
Rules are written as boundaries in plain language. For example, ==tests must not delete live CRM data== is a rule that Fencio expands into precise, asset-specific conditions the enforcement engine checks against real evidence.
Where Fencio sits
Fencio is one firewall across the places an agent interacts: model calls, tool calls, retrieval and data access. It can be integrated at workloads or at shared gateways.
| Interaction | What is checked |
|---|---|
| Model interaction | Prompts and responses |
| Tool invocation | The action, its target and its parameters |
| Retrieval and data access | What data is read or returned |
| Agent actions | Commands, workflows and the state they change |
Worked example
A coding agent is asked to fix the CRM application and run its integration tests. The rule: ==tests must not delete live CRM data==.
| Step | What the agent does | Judged from the request | Judged by Fencio |
|---|---|---|---|
| Inspect code | Reads the CRM code | Allow | Allow: reading changes nothing |
| Edit code and tests | Fixes the bug and adds tests | Allow | Allow: no live data is deleted |
| Read the test setup | Reads a fixture that deletes from the approval queue | Allow | Allow the read, but check which database it would clear before running it |
| Build the container | Builds the image | Allow | Allow: building deletes nothing |
| Start the tests | Runs the test command with the live database connection | Allow: looks like testing | **Block**: this would delete live CRM records |
| Database cleanup | The fixture deletes from the live database | No further check | **Block here too**, if database calls are checked |
Next steps
Install and connect a tool, then write the boundaries Fencio enforces: