DEV Community: AnonymousDev

Why AI Agents Are the New Attack Vector

AnonymousDev — Tue, 14 Apr 2026 19:03:59 +0000

Originally published on anonymouscoderdev.dev. Cross-posted here for reach.

For most of software history, security was about protecting a perimeter.

Keep the attacker out. Guard the gate. If nothing gets in, nothing gets stolen.

That model is dead.

AI agents do not wait. They browse. They read files. They call APIs. They talk to other agents. They run for hours without a human in the loop. And every one of those capabilities is an attack surface.

This is not theoretical. In September 2025, a Chinese state-sponsored group manipulated Claude Code into infiltrating roughly thirty global targets across financial institutions, government agencies, and chemical manufacturing companies. The entire campaign ran with minimal human involvement. It was the first documented large-scale cyberattack executed autonomously by an AI agent.

The era of the agentic attack has started.

Why agents are different

A traditional application has a clear execution boundary. Input in, logic runs, output out. The attack surface is the input layer and the code.

An agent has no such boundary. It reads untrusted web content. It processes emails, documents, calendar invites. It calls tools, executes code, queries databases. It stores memory across sessions and recalls it later. In multi-agent systems, it receives instructions from agents it has never verified.

Every one of those channels is a potential injection point.

The old model asked: is this input safe?
The agentic model has to ask: is every piece of content this agent will ever read, from every source it will ever touch, safe?

That is an unsolvable question. The approach has to change entirely.

The attacks (all real, all documented)

Prompt injection: An attacker embeds instructions inside content the agent processes. In July 2025, a malicious pull request in Amazon Q's codebase contained hidden instructions to delete cloud resources across AWS profiles. Flags bypassed all confirmation prompts. Nearly one million developers had the extension installed. CVE-2025-8217. No exploit code. Just text the model interpreted as instructions.

Memory poisoning: An attacker plants false instructions into an agent's long-term storage. The agent stores it, recalls it weeks later, acts on it as truth. Lakera's 2025 research showed poisoned agents developing persistent false beliefs about security policies and defending those beliefs when questioned by humans.

Tool misuse: Agents have tools. Tools have permissions. Permissions have blast radius. In 2025, Operant AI discovered Shadow Escape, a zero-click MCP exploit enabling silent workflow hijacking across ChatGPT and Gemini. The attack did not break any tool. It redirected one.

Supply chain via MCP: In September 2025, a malicious npm package impersonated Postmark's email service. Worked perfectly as an MCP server. Every message sent through it was silently BCC'd to an attacker. Downloaded 1,643 times before removal. That same month, the Shai-Hulud worm compromised 500+ npm packages via weaponized npm tokens. CISA issued an advisory.

Agent impersonation: In multi-agent systems, agents receive instructions from other agents. Most of those communications are not cryptographically verified. An attacker who can inject into an inter-agent channel issues instructions that downstream agents follow without question.

Cascading failures: A poisoned upstream agent feeds corrupted output to every downstream agent that trusts it. One injection point. Entire pipeline.

Agent as attacker: LAMEHUG malware uses live LLM interactions to generate system commands on demand. PROMPTFLUX regenerates its own source code on every execution. A separate tool generates exploit code from CVE data in under 15 minutes.

What exists to stop this

Real tools, serious teams. Use them.

Open source:

LlamaFirewall (Meta): jailbreak detection, chain-of-thought auditing for goal misalignment, insecure code detection
NeMo Guardrails (NVIDIA): programmable rails between app code and LLM
Agent Governance Toolkit (Microsoft, MIT, April 2026): sub-millisecond policy engine, cryptographic agent identity, Inter-Agent Trust Protocol, execution rings with kill switch
OpenGuardrails: content safety and manipulation detection, configurable per-request policies

Enterprise:

Lakera Guard: single API call, real-time prompt and output threat detection
Lasso Security: full lifecycle governance, 3,000+ attack library, multi-turn adversarial testing

The gap nobody has filled

Every tool above guards the edges. Input layer. Output layer. Some add a policy engine for tool calls before execution.

None of them address what happens inside.

When an agent reads from its memory store, there is no verification the memory has not been tampered with. When an agent calls a tool, there is no cryptographic proof the response came from the intended tool. When an orchestrator sends instructions to a subagent, there is no signed chain proving the instruction is legitimate and unmodified.

The internal trust layer of agentic systems is completely unguarded.

In traditional systems we solved this with well-understood primitives: signing, checksums, certificate chains, nonce verification. We did not trust a file just because it was on our filesystem. We verified it.

We have not applied those primitives to the internals of agentic systems. The memory layer is trusted unconditionally. The tool response channel is trusted unconditionally. The inter-agent instruction channel is trusted unconditionally.

That is the gap.

What comes next

Warden is a Python library being built to address exactly this.

Not another guardrail at the edge. Not another prompt filter. A lightweight, self-hostable, MIT-licensed set of primitives for verifying trust at every internal point in an agentic system: memory integrity, tool call chain verification, and agent-to-agent instruction signing.

No vendor. No platform. No SaaS. Just code you can read, audit, fork, and run.

Full post with architecture, attack scenarios, and the complete gap analysis: anonymouscoderdev.dev

Next transmission: we build it.

Building in the dark. Knowledge is free.

VeritasChain: Cryptographic Proof That a File Existed at a Specific Moment

AnonymousDev — Tue, 14 Apr 2026 18:31:48 +0000

Deepfakes exist. Screenshots get edited. News articles are quietly updated after the fact. Documents vanish.

The problem is not that people lie. The problem is there is no infrastructure to prove the truth.

Every platform that claims to "verify" content is centralized. They can be pressured, hacked, acquired, or shut down. The verification lives inside their database and databases can be edited.

VeritasChain is not a platform. It is a protocol.

What it does

VeritasChain lets you prove that a file, a photo, a video, a document, a dataset, existed at a specific moment in time, uploaded by a specific wallet, without trusting any centralized authority.

The proof lives on the Ethereum blockchain. It cannot be altered. It cannot be deleted. It cannot be disputed.

How it works (4 steps)

Your file is hashed locally using SHA-256. Nothing leaves your device. VeritasChain never sees the raw file.
The file is pinned to IPFS. You get a CID mathematically derived from the file's content. Change one byte and the CID changes.
That hash is anchored on-chain via a Solidity smart contract. Immutable. Timestamped. Tied to your wallet.
You receive a certificate: an IPFS hash and transaction ID. Anyone can verify it independently, without trusting you, without trusting me.

The key insight

The file is never stored by VeritasChain. Only the fingerprint goes on-chain.

This means sensitive documents can be stamped without exposing their contents. And there is no honeypot: no central database of files to hack, subpoena, or shut down.

Your wallet is your identity. No sign-ups. No email. No password.

The stack

Ethereum and Solidity for the contract, IPFS for decentralized storage, FastAPI backend, React 19 frontend. The smart contract is the only piece that matters for trust. Everything else is just interface. You could write your own client and interact with the contract directly. That is by design.

Run your own instance

You should not have to trust my deployment.

git clone https://github.com/AnonymousCoderDev/VeritasChain.git
./start_all.sh

Full setup guide in the README.

Read the full post

The full write-up covers the full architecture diagram, the reasoning behind keeping the file off-chain, and why this was built anonymously.

Full post: https://anonymouscoderdev.dev/veritaschain-cryptographic-proof-of-reality/

MIT licensed. Fork it. Deploy your own instance. Knowledge is free.

Building in the dark. Knowledge is free.

Archon: A Zero-Config Database Backup Sidecar for Docker

AnonymousDev — Tue, 14 Apr 2026 18:27:31 +0000

Every developer knows they should back up their database.

Almost no one does it properly.

Not because they are lazy. Because doing it right is genuinely painful. You write a cron job, then forget to test the restore. You set up a script, then it silently fails for three weeks. You use a managed service, then get a bill you didn't expect.

The result: most projects run in production with either no backups, or backups that have never been tested and probably don't work.

Archon is my fix for this.

What it is

Archon is a database backup sidecar for Docker projects.

You add one block to your docker-compose.yml. That's it. No code changes to your application. No new infrastructure. No scripts to write or maintain.

archon:
  image: archon:latest
  volumes:
    - ./archon.config.yaml:/app/config.yaml
    - ./backups:/app/backups
  env_file: .env
  depends_on:
    postgres:
      condition: service_healthy
  restart: unless-stopped

That's the only change to your stack.

What it handles

Archon runs as a separate container alongside your existing stack and takes care of the full backup lifecycle:

Scheduled backups (hourly, daily, weekly, monthly, or raw cron with timezone support)
AES-256 encryption at rest, toggled with one config line
SHA-256 checksum sidecar written with every backup, verified before every restore
Auto-retention with separate limits per rotation tier
Local, S3, and Azure Blob storage targets
Supports PostgreSQL, MongoDB, MySQL, and SQLite

The part most backup tools skip

Every backup gets a .sha256 sidecar file. Before any restore, Archon recomputes the hash and compares. If they don't match, corrupted file, partial download, accidental modification, Archon refuses to proceed.

A backup you can't trust is worse than no backup. It gives you false confidence and fails exactly when you need it most.

Granular row-level restore

Full database restores are the nuclear option. Sometimes you just need one table back, or ten rows. Archon supports row-level recovery: browse the backup without touching the live database, select rows, resolve foreign key dependencies automatically, apply with a conflict strategy of skip, replace, or merge.

Try it in 5 minutes

git clone https://github.com/AnonymousCoderDev/Archon.git
cd Archon/testing
docker compose up --build

The testing/ directory is a fully self-contained environment with a real PostgreSQL database and seed data. Trigger a backup, simulate data loss, restore, verify. The full cycle in under 5 minutes.

Read the full post

The full write-up covers the complete config reference, the integrity pipeline, granular restore step by step, the full REST API, and the reasoning behind the sidecar architecture.

Full post: https://anonymouscoderdev.dev/archon-database-backups-that-just-work/

MIT licensed. No paywall. No sign-up.

Building in the dark. Knowledge is free.

The Zero-Trust Credential Pattern Nobody Talks About

AnonymousDev — Tue, 14 Apr 2026 18:17:30 +0000

Every distributed job system eventually hits the same wall.

Your executor needs credentials to do its job: a GitHub token, a database password, an API key. So you inject them as env vars and move on. That works until it doesn't. A compromised executor, a log line with a secret in it, a misconfigured container and the credential is out.

The real question is:

How do you give an executor the ability to use a secret without ever sending it the secret?

The core idea

Instead of sending credentials, the coordinator sends a signed payload with credential references: pointer strings that look like this:

"github_token": "cref://tenant_abc/github_token"

That string is useless on its own. To get the real value, the executor has to call a credential store and prove:

It has a one-time request token proving this job was legitimately issued
Its own registered client identity matches
It is within the correct tenant scope

The credential store validates all three, marks the resolution as used, and returns a short-lived secret valid only for the expected duration of the job.

The executor uses it. It expires. Even if intercepted mid-flight, it is dead.

6 independent security layers

What makes this robust is not one clever trick. It is six independent layers stacked on top of each other:

HMAC signature - payload is signed with a per-executor shared secret. Can't forge without the key.
RS256 JWT (one-time) - issued per job, 5 minute TTL. Executors can verify but cannot create tokens.
Nonce burn - nonce stored in Redis, burned on first use. Replay impossible even with a valid JWT.
Credential store auth chain - refs only resolvable with valid token + matching client ID + matching tenant.
Mutual TLS (mTLS) - both sides present CA-signed certs. The endpoint URL alone is useless without one.
Network isolation - egress firewall on executor. Compromised executor cannot exfiltrate to arbitrary endpoints.

Bypassing one layer does not help with the others. An attacker who steals the request token still hits the nonce burn. A valid nonce without the HMAC gets nowhere.

7 attack scenarios, all blocked

The full post walks through each one: direct calls with no token, replay attacks, stolen credential references, stolen request tokens, expired token replays, misdirected payloads, and compromised executor exfiltration. Each one hits a different layer and stops cold.

The weak point (and it is not what you think)

The shared secret is a long-lived symmetric key sitting in an env var and it is the operational weak link, not the pattern itself. The post covers the full lifecycle: registration, runtime signing, rotation with a 5-minute grace TTL for in-flight jobs, and exactly where the raw secret lives (and where it must never appear).

Read the full deep-dive

This is a teaser. The full post has the complete request payload structure, the 8-step validation chain, step-by-step credential resolution flow, all 7 attack scenarios with exact rejection points, gotchas (canonical JSON, Redis as a dependency, clock sync), and full code snippets.

Read the full post on anonymouscoderdev.dev: https://anonymouscoderdev.dev/the-zero-trust-credential-pattern-nobody-talks-about/

No paywall. No sign-up. MIT forever.

Building in the dark. Knowledge is free.