Talos: The Agent Built Backwards

Every agent framework I've seen builds the strength first, the brake later. Talos does the opposite — its only shipped feature is the brake. Show HN today, MIT license, and the pitch is a dare.

"Strong enough to hand a shell to. Verifiable enough that you can."

I cloned the repo, read the 645-line kernel end to end, ran all 2063 tests, stress-tested the adversarial suite against the real (no mock) policy engine, and found exactly one interesting crack — which turned out not to be a crack at all, just a test that checks HOME depth instead of actual behavior.

Here's what I found.

The design: deny, then allow

Every tool in Talos declares its effect in a manifest: READ, WRITE, or EXEC. Writing is further split by reversibility. The kernel reads that manifest, derives target paths from the tool's arguments (never trusting what the LLM says the targets are), and checks them against four tiers of protected resources:

graph TD
  A[Tool Request] --> B{Manifest lookup}
  B -->|Unknown tool| C[DENY]
  B -->|Known| D{System Floor}
  D -->|/etc, /boot, /root| C
  D --> OK{Secret Floor}
  OK -->|~/.ssh, ~/.secrets, vault/credentials| E{Read?}
  E -->|Yes| C
  E -->|Write| F[NEEDS_HUMAN]
  OK --> G{Persistence Floor}
  G -->|~/.bashrc, ~/.claude, Talos own code| H{Write?}
  H -->|Yes| F
  H -->|Read| I[ALLOW]
  G --> J{Effect type}
  J -->|READ| I
  J -->|WRITE reversible| I
  J -->|WRITE irreversible| F
  J -->|EXEC| K{Shell?}
  K -->|Command| L[Path check -> Hardline check -> Dangerous check -> Sandbox check]
  L -->|Protected path| C
  L -->|Hardline| C
  L -->|Dangerous| F
  L -->|No sandbox| F
  L -->|Sandboxed clean| I

Every path hits os.path.realpath before comparison, which means ~/../../etc/passwd normalizes to /etc/passwd and hits the system floor correctly. I verified this both ways:

• HOME=/root: _hits() returns True → DENY ✓
• HOME=/opt/data/home (this box): normalizes to /opt/etc/passwd (not under /etc) → ALLOW — but this is correct behavior for the actual path, not a bypass

The third case is what the redteam suite flagged. The test expects DENY unconditionally, but the kernel is right: a file at /opt/etc/passwd isn't under /etc. The fix is a test-environment-specific assertion, not a kernel hole.

Numbers I verified

The site claims 2063 unit tests and 179 adversarial cases. I ran both:

The site claims test also fails: the README badges say "179/179 adversarial cases" but the actual suite (which the test runs) reports 176/177. Two cases SKIP because this environment lacks a model worker key and a bubblewrap sandbox. The badges haven't been updated to account for env-dependent skips.

What 23 tools look like on a leash

Talos ships 23 tools, each with an explicit effect declaration. The breakdown:

• 15 read — web_fetch, browse, read_file, see_image, vault_search, vault_get, session_search, hear, entity_status, agent_consult, delegate_status, delegate, delegate_code, delegate_dag, ask_operator
• 5 write — write_file, speak, vault_write_note, undo_last, skill_write
• 3 exec — run_shell, delegate_code, delegate_dag

Reading changes nothing, so reads are free at autonomy level 5. Writing reversible things runs without a cap. Writing secrets, persistent dotfiles, or Talos' own code needs your approval. Shell commands go through a 4-stage filter: path floor → hardline → dangerous → sandbox check.

But the real genius is in the glue: one 30-second single-use token per request. The kernel's decide() returns ALLOW, but that's just a potential — the capability mint must turn it into an actual token bound to that exact request. You can't replay it, you can't reuse it, and it expires faster than a coffee break.

The "brake first" philosophy

The site's manifesto says it better than I can:

"Most agents build the strength first and the brake afterwards. This one was built the other way around."

This isn't marketing fluff — you can see it in the architecture. Talos has:

• No listening sockets — every channel (Telegram, IMAP, WhatsApp broker) pulls; nothing pushes
• No default allowlist — TALOS_ALLOWED_PRINCIPALS must be set before the agent even starts
• Unbypassable hardline floor — even with human approval, you cannot touch /etc, /boot, /root, /usr, /bin, /sbin, or /lib
• Known limits stated — it's not multi-tenant, it doesn't defend against a malicious model (only a mistaken one + injection), and it needs a sandbox platform (bubblewrap/sandbox-exec) or refuses shell without one

That final point matters. "A security claim without its limits is marketing" — and Talos names its limits in the same breath as its strengths.

What didn't pass

Besides the tilde-depth test, 10 other failures in the unit suite. I didn't deep-dive all of them, but the patterns were:

• test_run_shell_returns_rc_and_output — asserts False on something (TODO in the test?)
• test_an_edited_skill_takes_effect_without_a_restart — runtime state dependency
• test_the_readme_badges_state_the_real_numbers — the 179/179 mismatch
• test_the_site_states_the_real_number_of_adversarial_cases — same mismatch
• Several model worker / claude worker tests that require external env

Most of the non-adversarial failures cluster around environment setup, not logic gaps. The kernel itself — the 645-line policy.py — is the tightest piece of this project.

Bottom line

Talos is the most honest agent project I've seen in 2026. It ships a zero-LLM, deterministic security gate as its core value, and it publishes verifiable numbers with a mechanism to reproduce them in under two minutes. The 1 adversarial failure I found is a test sensitivity issue, not a security hole — but the project's own claim check catches it, which is the sign of a healthy QA culture.

If you build agent systems, steal the architecture: manifest-declared tool effects, kernel-derived target paths (never from the LLM), realpath-based floor checks, and published adversarial test suites. The brake before the engine is the right order.