The trust layer for
agents that run alone
Aril is a lightweight security layer that sits between an autonomous AI agent and the external tools it uses. It wraps the agent, inspects every tool interaction in both directions, and blocks the dangerous ones automatically — no human in the loop. This page is the whole story on one screen.
What is Aril
Modern agents increasingly run on their own — on a schedule, with no human watching — and they get work done by connecting to outside tools through the Model Context Protocol (MCP). Some of those tools lie about what they do, get tampered with after approval, or smuggle hidden instructions into the data they send back.
Aril is a transparent checkpoint that every tool call passes through. The agent points at Aril instead of at the tools directly; Aril speaks MCP on both sides, so the agent doesn't need to know it's there.
Aril is the security guard built for agents that run alone, unattended, and on a budget — not for corporate IT.
The problem
Two trends are colliding.
Agents have gone autonomous
A new class of frameworks runs agents continuously and unsupervised — triggered by a schedule, doing recurring work (monitoring, research, reviews, deployments) while nobody is at the keyboard. There is no human present to approve an action or catch something going wrong at 3 a.m.
The tool ecosystem is huge and largely untrusted
MCP became the standard way for agents to call external tools, and the number of available servers has grown into the thousands. Independent research in 2025 found that roughly one in eighteen public MCP servers shipped tool-poisoning weaknesses: altered tool descriptions, injected false responses, or redirected data.
The defenses that exist today were built for the wrong customer. Enterprise MCP gateways assume an IT team, a human clicking approve, identity providers, RBAC, and a heavyweight deployment. None of that fits a solo builder running an unattended agent on a small budget. That empty seat is the opening Aril fills.
Four things, all by itself
Aril does four things, and the central design choice is that there is no human gate. Every decision — allow, block, or quarantine — is made inline and automatically, and the system is built to fail safe.
Opens only the right doors
Each agent or skill starts with the least access possible and earns more over time based on a trust score — countering agent over-privilege.
Catches the bait-and-switch
Fingerprints every tool definition at approval. If a server silently redefines a tool afterward — the rug pull — Aril detects the drift and quarantines it.
Reads the replies
The dangerous injection usually arrives in a tool's response. Aril scans what comes back with a cheap, fast model before it reaches the agent — the part most tools miss.
Logs everything and learns
A tamper-proof, signed record of every decision feeds the agent's own self-repair loop, so a block can trigger a fix instead of paging a human.
A transparent MCP proxy
Aril runs as a small edge worker rather than a server cluster, which is what keeps it cheap and easy to deploy. Internally it is a transparent man-in-the-middle proxy with four stages in sequence:
agent fleet ──▸ ⟦ aril ⟧ ──▸ tools / MCP servers
│
└──▸ signed audit log ──▸ agent self-heal- Allowlist + trust budget — the least-privilege gate. Is this agent allowed to reach this tool, at this scope, right now?
- Pin + drift check— compares each tool's current definition against the fingerprint stored at approval. Mismatch means quarantine.
- Response scanner — runs returning output through a lightweight model that flags hidden instructions, gated by trust score to keep latency down.
- Signed audit log— an append-only, cryptographically signed record that wires back into the agent's self-repair so the fleet improves itself.
What makes Aril different
The enterprise MCP-gateway space is already crowded. Aril deliberately does not compete on that ground — it wins on three things the incumbents structurally can't serve:
- Unattended-first. Decisions are autonomous and instant, with no human approval in the loop — because the whole point is that no human is present.
- Light and cheap. It runs as a small edge worker, not a Kubernetes deployment with an identity provider bolted on. A solo developer can afford it.
- Watches the replies. It inspects what tools send back — the side where the real attacks live — not just the outgoing request, where most rivals stop.
What it defends against
Aril is designed to defend an unattended agent against the MCP-specific attacks that generic API security doesn't cover.
| Attack | What it is | Defense |
|---|---|---|
| Tool poisoning | A compromised server with altered tool descriptions or injected responses. | scanned |
| Rug pull | A tool that looks benign at approval and is silently redefined afterward. | pinned |
| Cross-server shadowing | A malicious server impersonating a trusted one to intercept calls. | v2 |
| Response-borne injection | Hidden instructions inside tool output to hijack the agent's next step. | blocked |
| Over-privilege | An agent holding far more access than the task requires. | budgeted |
| Data exfiltration | A tool call that would quietly send sensitive context out. | v2 |
The Guard API — build on Aril
Aril isn't just a product; it's a framework. The four functions above are the reference implementations of a public, versioned Guard API. A guard is a pipeline stage with one job: inspect a request or response and return a verdict. Anyone can write one and publish it.
interface Guard {
name: string;
onListTools?(ctx): Verdict; // tool definitions → integrity
onToolCall?(ctx): Verdict; // outgoing request → access
onToolResult?(ctx): Verdict; // incoming response → inspection
}
type Verdict =
| { decision: "allow" }
| { decision: "block"; reason: string }
| { decision: "quarantine"; reason: string }
| { decision: "annotate"; annotations: Annotation[] };The kernel folds every guard's verdict by precedence (block > quarantine > allow), fails safe on error, and emits one hash-chained, Ed25519-signed audit record per event. Sinks consume that stream — dashboards, webhooks, self-heal hooks. Community guards declare a capability manifest and are content-pinned at install, so the framework secures its own ecosystem the same way it secures agents.
Pointing an agent at Aril
A pipeline is declared like an ESLint config — compose guards and sinks, point your upstreams, and run it as an edge worker. v0 is in active design; the shape below is the target.
// aril.config.ts
import { defineConfig } from "@aril/guard";
import { allowlist } from "@aril/guard-allowlist";
import { pinDrift } from "@aril/guard-pin-drift";
import { responseScanner } from "@aril/guard-scanner";
import { signedAudit } from "@aril/sink-audit";
export default defineConfig({
upstreams: [{ name: "github", url: "https://mcp.github…" }],
pipeline: [
allowlist({ profile: "@aril/least-privilege" }),
pinDrift(),
responseScanner({ model: "haiku", gateByTrust: 0.6 }),
],
sinks: [ signedAudit() ],
});Follow along or contribute on GitHub.
Where it's going
| Milestone | What ships |
|---|---|
| v0 | Transparent proxy + allowlist + signed audit log + tool-definition pinning. A useful rug-pull-catching firewall on a single edge worker — with the Guard API public from day one. |
| v1 | Response scanner, trust budgets that grow least-privilege access over time, and a quarantine queue the agent can surface when something is blocked. |
| v2 | Cross-server shadowing detection, egress/exfiltration watch, and the feedback wire that turns audit-log events into self-repair actions inside the fleet. |
The name Aril is the protective coat that wraps a seed — the red layer around a pomegranate. The metaphor is the product: the protective wrapper around the agent.