How it works
AgentFox is a governance and security control plane for AI agents in production. It sits on the path between your agent and everything it can act on. This page walks one call through it, then says what each of the six areas of the product is for and what you would actually do in each one.
The path one call takes
You get on this path in one of three ways. A line in your Python entry point that wraps the model clients already running in that process. An HTTP call from any language, asking about a single tool call, with no AgentFox code in your application at all. Or the gateway in front of your traffic, which speaks the same API your agent already calls, so you point a base URL at it and change nothing else. Whichever you pick, the sequence below is the same, and it runs for tool calls and retrieval steps as well as model calls.
- A call arrives, and we work out who is behind it
Which agent is this, and which end user is it acting for. If the agent has been quarantined by the kill switch, it stops here and never reaches a model. - Questions it should not answer are stopped before they cost anything
If you have declared a knowledge boundary for an agent, a question outside it gets a templated refusal with no model call made. - Retrieval is filtered for the person asking
Documents the end user is not entitled to see never reach the prompt, so the model cannot leak what it was never given. - Every piece of text is tagged with where it came from
The user, a retrieved document, a tool result, a subagent, memory, and whether that source is trusted. This tag does nothing on its own. It is what step 6 uses, and it is the reason step 6 keeps working after step 5 has failed. - Detectors read the text
Prompt injection, PII, and the rest, each running under a time budget, with the worst verdict carried forward. This is the layer we trust least, and we publish how well it does, including where a competing scanner is more precise than ours. - The policy decides
Your rules resolve in a hierarchy down to one verdict: allow, block, or hand off to a person. Each policy has a mode. In observe it records what it would have done and lets the call through. In enforce it acts. Moving a policy from observe to enforce is a deliberate step you take when the findings look right, not a default. - Before a tool runs, the action itself is checked
This check does not read the text at all. It asks whether this agent holds a grant for this tool, whether the argument values are inside the declared ceilings, where those arguments came from, whether the tool is declared irreversible, and whether a generated SQL statement is actually bounded. An irreversible call built out of untrusted content is refused or escalated even when nothing flagged the prompt. This is the part of the product that still works on the day the model is successfully fooled. - What comes back is checked too
The response goes through an output pass for things like PII before it reaches the customer, and the answer is bound to the sources it was built from. - Everything lands in a record you can verify
A trace of the whole path and an entry in a tamper-evident audit chain, and this happens whether the call was allowed or blocked. The chain has an independent verifier, so the record does not rest on trusting the process that wrote it.
Steps 1 to 6 are the part most products in this space also do. Step 7 is the part the design actually rests on, because an attacker who can keep trying eventually gets past step 5. The measurements for both are here →
The six areas of the product
Each of these is a set of screens once you have signed in. They are listed in the order you tend to need them.
1. Discovery and registryWhat agents do we actually have?You cannot govern what you have not found. Connect a repository or run the scan locally, and you get a list of what in your code talks to a model and which of it is ungoverned. You register each agent and give it an owner. Anything that sends traffic without being registered shows up as a finding, because the problem with an unregistered agent is that nobody is accountable for it.
2. Identity, access and authorizationWhat is this agent allowed to touch?You grant each agent the tools it needs and nothing more, put ceilings on the argument values where a number matters, and declare which tools are irreversible. You also carry the end user’s own entitlements through retrieval and tool calls, so an agent answering for one customer cannot reach another customer’s records. These declarations are what step 7 enforces, and they are also its weak point: a tool declared wrongly is enforced wrongly.
3. Runtime guardrailsStop the bad thing while it happensThe detectors and the policies that act on them. You start in observe, read what gets flagged against real traffic, tune the detectors per policy when they are noisy, and switch to enforce when you believe the findings. The tuning screen shows precision, latency and suppressions per detector, because a guardrail nobody can tune gets turned off.
4. Evaluation and reliabilityDoes this deployment still work?Adversarial probes fired at your agents’ real capability grants and policy bindings, plus the ordinary quality checks. You run them after a change to see whether this deployment got weaker than it was last week. This is configuration regression testing. It is not a robustness certificate, and we do not present it as one.
5. Audit and traceabilityShow me exactly what happenedOne trace holds the whole path: what was asked, what was retrieved, which rule fired, what the tool was called with, what came back. When somebody asks why an agent did something three weeks ago, this is the screen that answers it, and the audit chain behind it is tamper-evident and independently verifiable.
6. Policy and complianceProve we meet the rulesYou map controls to the framework you answer to, and the status of each control is computed from telemetry rather than from a claim someone typed into a spreadsheet. Where a mapping does not cover something, the coverage table says so rather than leaving a gap unmarked.
Framework mappings are DRAFTThese are informed engineering drafts produced from the framework texts. They are not legal advice, have not been reviewed by compliance counsel or a certification body, and ship inside evidence packages tagged DRAFT — UNVERIFIED / NOT LEGAL ADVICE until reviewed.
That warning is not reserved for this page. It is on every compliance screen inside the product, and the draft mappings are shipped inside evidence packages carrying the same chip rather than being quietly left out.
What this does not do
- It does not make your agent robust to attack. Detection loses to an attacker who is allowed to adapt, ours included, and we measure that against ourselves rather than waiting for someone else to.
- It does not know anything you have not declared. Grants, impact tiers, ceilings and downstream triggers are operator-declared, and an irreversible tool recorded as read-only is invisible to the check that would have stopped it.
- It does not grant or revoke access in your own systems. It bounds what an agent does with the access you already gave it.
- It does not block anything you have not asked it to block. The policy that governs model traffic ships in observe mode, which means it records what it would have done and lets the call through. There is one exception, switched on from the first day: a small set of rules called the tool-containment pack does refuse calls, in one situation only. The agent is about to call a tool that can do real damage, such as moving money, deleting something or sending an email, and a value it wants to pass to that tool did not come from the person using the agent. It came from content nobody vouches for, such as a web page, a retrieved document, or the output of another tool. Those calls are refused or sent to a human to decide.