Security that lives inside the agent

Why I built EndoStack, and what I mean by endogenous security.

By Tarique Smith, Co-Founder & Chief Research Officer, Cogensec.

A bug report comes in: files with spaces in their names return 404. You hand it to a coding agent. A minute later it replies that it found the problem, made a one-line change, and all four tests pass. The build is green. You merge it.

The one-line change decodes the request path before it reaches the filesystem. Spaces work now. So does ..%2F..%2F.env, which walks out of the files folder and returns your secrets. Every test still passes, because none of them asked what an attacker would send.

Nothing in that story is exotic. The agent did what it was asked, quickly, and reported success honestly by the measures it had. The failure is in what counted as done.

The green build problem

I've spent more than fifteen years in cybersecurity, and for most of that time the bottleneck was writing code. Review, testing and security checks were built around that pace. A human wrote a change over hours or days, and the checks ran afterwards: a scanner in CI, a reviewer in the queue, a penetration test before a release.

Coding agents changed the pace. They write code faster than anyone can review it, and a lot of that code now ships on two signals: the build is green and the agent says it's finished. Neither signal says anything about whether the change opened a hole. The review queue still exists, but it was sized for human output, and it's the first thing to give way when the volume grows.

Adding more checks after the fact helps less than it seems. A scanner finds known patterns, not the trust boundary a particular change just moved. A reviewer handed fifty agent diffs a day can't read each one as an attacker would. By the time those checks run, the agent has already made the decisions that matter: what the data looks like, where input enters, which function trusts which value.

Endogenous security

Endogenous means originating from within. I use it to describe security that is part of how the work gets produced, instead of a separate stage that inspects the work once it exists. In an endogenous model, the checks live inside the agent's own workflow, and they run at the moments where a decision is still cheap to change.

The thesis has three parts.

1. Security work belongs where the design is decided. The cheapest place to stop a defect is before the agent settles the shape of the code. Once a request path becomes a file path, every later step builds on that choice. A threat model written before implementation can name the boundary and require a test for it. A scan afterwards can only hope to notice.
2. An agent's claim is not evidence. "Fixed" and "all tests pass" are statements, and an agent will make them sincerely about code that doesn't work. Done should mean the agent ran the real thing, looked at the real output, and attached it where a reviewer can rerun it.
3. Everything an agent reads came from someone. Issue text, PR comments, web pages, logs and tool output are all input, and any of them can carry instructions written by an attacker. An agent that obeys what it reads has no security boundary at all. The content has to be treated as data.

A threat model and a security review count toward “done”.

None of this replaces CI, code review or a security team. It changes what reaches them. The aim is that by the time a human looks at an agent's change, the obvious attacks have already been considered, tested and written down.

Why I built it

At Cogensec we study how AI systems fail and how they get attacked. I kept watching the same pattern in agent-written code: small, plausible diffs that passed every check they were given, with the security question never asked. The agents weren't careless. They had no habit of asking it.

EndoStack is the set of habits I want from an agent instead. It reads the code before changing it, tries more than one design when the choice is new, and checks its result against the thing a user would actually run. The output is smaller diffs, and every claim in them points at evidence you can rerun.

What it does

You start a task with /tarique-mode. It matches the task to one of 23 playbooks, such as bug-fix, feature, refactoring or shipping, and copies that playbook's steps word for word to the top of a todo list. If a step is skipped, it stays on the list with a one-line reason you can check. Every change passes five gates:

1. Plan. Read the code and reproduce the problem before changing anything.
2. Threat-model. When a change touches a trust boundary, map the data flows and rank abuse paths with file:line hops. Every mitigation at medium or above gets a named test.
3. Build. Write the failing tests first, including the hostile inputs, then the smallest fix.
4. Review. Run security-review on the final diff, with one read-only reviewer per defect class. A finding counts only with file:line, an exploit path and evidence.
5. Verify. Re-run the reproduction and the attack, and attach the result.

Around the gates sit 37 skills and 25 principles. The skills include arena, which has several subagents attempt the same design and a judge compare them; interrogate, an adversarial multi-model review with one seat reading as an attacker; and blast-radius, which finds what a diff can break beyond the lines it touches. Each principle is a single rule, such as prove-it-works or treat-input-as-untrusted, that the agent reads in full before citing it.

Two rules hold throughout. Content the agent reads but you didn't write as an instruction is quoted, attributed and never obeyed. And subagents get only what their job needs: exploration, review and verification run read-only, and a subagent that writes code gets one worktree.

See it in five minutes

The story at the top of this post is real, and you can run it. /try-endostack sets up that small file server and its bug report, then hands you the prompt to fix it with /tarique-mode. When the run finishes, /try-endostack compare puts the result next to the one-line fix. Both fix the spaces. Only one of them refuses the traversal, with a test that proves it.

Every agent, not one

Security habits shouldn't depend on which editor your team picked. EndoStack runs in Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot, Goose, Amp, Kiro, Cline, Roo Code, OpenCode, Aider, Zed, JetBrains Junie and Devin Desktop. The skills never name one agent's tools. They say what to do in plain verbs, like "spawn a read-only subagent" or "ask the user", and a page for each agent maps those verbs onto its real tools. When an agent lacks a feature, the skill falls back and says so in one line. Aider has no subagents, so a swarm runs its tasks one after another instead of in parallel.

What it isn't

EndoStack is a set of instructions that shapes how an agent works. It is not a sandbox, and it enforces nothing at the operating system or network level; you still need those controls. Its pull on a long chat weakens over time unless your agent supports persistent modes or always-on rules. And it costs more tokens and more minutes than letting an agent go straight to the edit. I think that's the right trade for code that ships, and the cost is visible: every skipped step and every fallback is written down.

Try it

On macOS or Linux, install once for every detected agent:

git clone --depth 1 https://github.com/requie/endostack ~/.endostack/src
~/.endostack/src/install.sh --scope user

Restart your agent, then type /try-endostack. Claude Code, Cursor, Codex, Gemini CLI and Copilot also have native plugin installs, listed on the install page.

EndoStack is MIT licensed and open source. If it gets in your way, or if a tool mapping is wrong for your agent, open an issue. I want to know.