Why Your First AICEP Agent Should Be a Security Agent (AICEP v0.2 draft)

AICEP v0.2 draft. Provided "as is", without warranty. Step-by-step: How to Build Your Security Agent. Normative rule: Security: External Intake Gate.

When you first seat AICEP, it is tempting to start with the fun agents: the one that writes, the one that researches, the one that builds. We recommend starting somewhere less exciting. Before your agents begin exchanging context with each other and with the world, give one of them a single job: deciding what gets in.

This article explains why we do it that way and how it works day to day. The companion guide has the exact rule text, templates, and install steps.

The problem: agents trust too easily

An AI agent reads everything as potentially useful. A link in a chat, a post someone shared, a package a tutorial recommends, a document with a helpful-looking instruction buried in it. Each of those is a door. Most are harmless. Some are not, and the ones that are not are designed to look harmless.

Human teams handle this with habits: you don't run attachments from strangers, you check where a download came from. Agent teams need the same habits, but written down, because an agent will do exactly what it is told and nothing it isn't.

So we wrote one rule and gave it to every agent: anything from outside goes to the security agent before anyone acts on it, installs it, or adopts it. That includes things the owner hands over. That last part matters. The owner is not the threat, but the owner can be fooled like anyone else, and a link that came from a trusted person is exactly the kind of link an attacker would hope to slip through.

We also say plainly that "another agent told me the owner approved" is not approval. Approval comes from the security agent's verdict, and for the riskiest things, from the owner directly.

One computer, one set of tools

All our agents share one working computer, separate from the owner's personal devices. That turns out to be a gift for security. The security agent installs its scanners once — ClamAV with community YARA rules, Trivy and OSV-Scanner for vulnerable dependencies, gitleaks for leaked secrets — and every review uses the same tools. Nothing gets installed on the owner's laptop or phone, and anything suspicious stays in a quarantine folder on a machine that holds no personal data.

The scanners are installed the same careful way we ask everyone else to install things: from the official source, with checksums verified and versions pinned, and never by piping a script from the internet straight into a shell.

What a review looks like

Every review follows the same path. The artifact is fetched into quarantine without running anything. If it's a package, its hash is compared with the one the official registry publishes; a mismatch ends the review right there. Then the scanners run, and then a person-style read: what does this actually do, what does it connect to, does it ask for credentials, does it contain text aimed at AI agents?

The answer is one of three verdicts: approved, approved with limits, or not approved. "With limits" is where most of the value lives. A news source might be approved for read-only requests, at most once an hour, as leads only, with every claim checked against the original. The limits are written out so the requesting agent knows exactly where the fences are.

Anything that would grant credentials, open remote access, touch production, or spend money gets a second signature: the human owner's.

A real example, including our mistake

Recently a news agent was asked to add a new public news site as a source. It asked the security agent first, as the rule says.

The security agent fetched the landing page and found an empty placeholder, so it reported that nothing was published. That was wrong. The real content lived inside an embedded frame that a raw fetch never sees. The news agent, looking through a real browser, spotted the links and came back.

On the second pass, the security agent checked every feed behind the page. They were plain pages with no forms, no logins, no scripts, and every story linked to posts on x.com. A few stories talked about AI prompts and a security bug, but as reporting, not as instructions. Verdict: approved with limits.

The site also linked to shared documents, each with a PDF download link. The documents were approved as plain-text reads. The PDFs were refused: same content, but as a downloaded file, which adds risk for no benefit. Link shorteners inside the documents were off-limits too, because you can't see where they go.

We share the mistake on purpose. A security process that never admits an error is one you can't trust. The fix — render pages in a real browser as well as fetching them — is now in our recommended practice.

The quiet parts: logs, secrets, and outbound checks

Three habits run in the background.

First, every time any agent sends something off our own channels — a web request, a message, an upload — it writes one line: when, which agent, which channel, what action, what target, what result. That log is how we answer "what left the building?" without guessing.

Second, credentials never appear in chat, files, or logs. They sit in a secret store, scoped as narrowly as possible, and rotate at least quarterly.

Third, the gate points outward as well as inward. Before any agent ships its own code, it runs the secret and dependency scanners on it. Our own work gets the same scrutiny as a stranger's.

Analysis before control

The security agent's default is to investigate and recommend, not to take over. It doesn't buy things, change DNS, publish, or touch live systems without the owner's go. It doesn't route around a block with a sneakier version of the same action. Its power comes from being the one place every outside thing must pass through, not from having its hands on every switch.

Where we're going next

The guide lists practices we recommend on top of the baseline: browser rendering alongside raw fetches, a written allowlist of approved sources with re-review dates, re-checking sources when they change, a small prompt-injection test set, software bills of materials and signature checks, daily scanner updates with a freshness check, per-agent expiring credentials, a two-person rule for credentials and production, an append-only verdict log, and a tested restore of the security agent's own setup.

None of this is exotic. It's the ordinary discipline of a careful team, written down so agents can follow it. Start with the security agent, and everything you build afterward stands on firmer ground.

Ready to set one up? Follow How to Build Your Security Agent.