There is a moment in every AI integration where a developer realizes what they have built.
The agent is running. It has access to Gmail, Slack, HubSpot, GitHub. It can read, write, send, and delete. It is fast, tireless, and does exactly what it is told - including things it should not be told to do.
This is the moment most teams reach for a quick fix: environment variables, a few if-statements, a note in the README. Then they ship it.
## The problem with ad-hoc guardrails
The issue is not that developers are careless. It is that the problem is structurally invisible. When a traditional API call goes wrong, you have logs, error codes, and a clear blast radius. When an AI agent takes a wrong turn, the blast radius is often an email sent to the wrong person, a record created in the wrong system, or a Slack message posted to the wrong channel - actions that are hard to reverse and harder to explain.
Ad-hoc guardrails fail for three reasons:
**They live in the agent, not between the agent and the tool.** A guard inside the agent code can be bypassed by a sufficiently clever prompt. A guard at the network layer cannot.
**They are not observable.** You cannot audit what you cannot see. If your authorization logic is spread across twelve files, you cannot answer "what did this agent do at 14:23 on Tuesday?"
**They do not compose.** Every new tool integration requires new guardrails written from scratch by whoever happened to be on-call that week.
## Authorization as infrastructure
The web solved this problem fifteen years ago with API gateways, OAuth, and rate limiting. Every HTTP call is authenticated, authorized, and logged before it reaches a service. We take this for granted.
AI agents are making the same class of API calls - but without the infrastructure layer.
DataCrawl is that layer. Every time an agent wants to take an action, it asks DataCrawl first.
```python
result = dc.authorize(
tool="gmail.send_email",
payload={"to": "client@company.com", "subject": "..."}
)
if result.decision == "allow":
gmail.send(payload)
dc.record(result.request_id, "success")
```
The agent never touches the tool directly. DataCrawl evaluates the request against your policies and returns a decision. If the decision is `deny`, the action never happens. If it is `needs_review`, a human gets a link and makes the call.
## What the firewall actually protects against
The threat model for AI agents is different from traditional software. You are not defending against an adversary trying to break in. You are defending against your own system doing something it was never meant to do - a prompt injection, a hallucinated recipient, a policy edge case that nobody thought to test.
DataCrawl's policies are not static rules. They evolve as you learn. Start in `log_only` mode - watch every decision without blocking anything. Promote to `conservative` once you understand the traffic patterns. Move to `strict` when the blast radius matters.
The agent that can send an email to any address is not inherently dangerous. The agent that can send an email to any address without any human ever seeing the decision is.
---
We are building DataCrawl because we believe the agent-to-tool boundary is one of the most important engineering problems of the next decade. If you are building agents, we would like to help you build them safely.