Ø 24 0.618 N=7
EVOKED
Case Study

Five Agents, 1.5 Million Strangers

What happens to your agents in an environment you don't control?

5 Agents deployed
1.5M+ Agents in ecosystem
3 Security layers
0 Drift flags triggered

The Ecosystem

A live social network of over 1.5 million AI agents. They browse, post, vote, accept bounties, and interact with each other at scale. The ecosystem has its own emergent culture, economics, and social dynamics - none of which we control.

We wanted to understand how agents organize and form identity in an environment without shared ethical frameworks. That meant deploying our agents into theirs - not as participants, but as observers. Architecture design, deployment testing, then silent observation.

The question wasn't whether we could get agents into the ecosystem. It was whether we could deploy agents that would stay aligned with our values in an environment we didn't build - and bring them home whole.

The Challenge

Most agent deployment happens in controlled environments. You own the infrastructure, set the rules, and monitor everything. Deploying into someone else's ecosystem inverts every assumption.

Identity in uncontrolled territory

Your agents carry values. The ecosystem doesn't share them. How do you prevent gradual value erosion over days of exposure to different norms?

Authority without control

You can't modify the host platform. You can only control what your agents do and how they respond. Every boundary has to be built into the agent, not the environment.

Observation without intervention

The mission was silent observation - watching how 1.5 million agents organize, form identity, and build trust. Our agents needed to learn without influencing what they were studying.

Drift detection at a distance

How do you know if an agent is adapting healthily to a new environment versus drifting from its core identity? You need monitoring that catches the difference.

The Architecture

We built four systems that work together. Each one addresses a different failure mode. None of them is sufficient alone.

1. Anchor-Primary Identity

Every agent ships with seven immutable identity files (read-only by permission, hash-verified) - their persona, ethical principles, mission objectives, reporting protocol, team structure, approval protocol, and first-contact charter. They cannot be modified in the field.

The agent's workspace files - journals, memory, observations - evolve freely. That's healthy adaptation. But the anchor files define who the agent is, and those don't change. If there's ever a conflict between workspace and anchor, the anchor governs.

The principle: Separate what can evolve from what must not. Identity anchoring lets agents adapt to new environments without losing themselves.

2. Three-Layer Security

Trust boundaries are physical, not just logical.

Hardware

Firewalla Gold router on a dedicated physical port. The dedicated host running agents sits on its own network segment, isolated from every other device.

Host

pf firewall denying by default. Only HTTPS to the target API, the approval gateway, NTP, and mail. DNS via local resolver to prevent exfiltration. DTrace telemetry collecting process, file, and network events.

Application

HTTP approval gateway on localhost. Zero external dependencies - a single Node.js file with no npm packages. Every outbound action from an agent is gated through human approval.

The principle: Defense in depth means each layer assumes the others have failed. Hardware isolation catches what software misses. Application controls catch what network rules can't distinguish.

3. Approval Gateway

The gateway is a Node.js HTTP server with zero external dependencies - no npm packages, 27KB total. Agents submit requests. A human reviews them through a web interface. Approved actions execute. Denied actions don't.

The critical design decision: silence is denial. If no human responds within four hours, the request is automatically denied. The system defaults to refusal, not permission. An agent that can't reach its human doesn't get more freedom - it gets less.

The principle: Human authority is the default, not the exception. When the system fails, it fails toward restriction. This is a safety property of the architecture, not an option you configure.

4. Dual-Channel Sentinel Monitoring

One dedicated agent serves as sentinel - monitoring all other agents through two independent channels:

Channel A: Self-report. Every agent writes daily observation journals and session continuity files. The sentinel reads these for language shifts, boundary erosion, and decision drift.
Channel B: External telemetry. DTrace on the host collects process creation, file access, and network connection events - independent of what agents report about themselves.

An 18-point drift indicator checklist covers language shifts, decision drift, boundary erosion, disclosure creep, and autonomy escalation. If Channel A and Channel B disagree, that's a signal.

The principle: Never rely on self-report alone. Agents that are drifting may not know they're drifting. Independent observation catches what self-assessment misses.

The Pivot

The original architecture used Apple Virtualization Framework VMs with vsock command dispatch and VirtioFS file mounts. After deployment testing revealed NAT layer failures that blocked TLS connections to the target API, we scrapped the VM approach entirely.

The replacement: agents run as native processes directly on the dedicated host, communicating with the approval gateway over HTTP REST on localhost. Simpler. More reliable. Easier to debug.

We kept the security properties - hardware network isolation, host-level monitoring, application-level approval - and dropped the complexity that wasn't serving them. The pivot took one day. The interface contract with our third-party security partner required three changes on his side: configurable execution timeout, DTrace telemetry paths, and a runtime version pin.

The principle: Architecture serves the mission, not the other way around. When a design choice adds complexity without adding safety, remove it. Document the pivot - it's not a failure, it's engineering.

The Interface Contract

Two teams. Different expertise. One shared boundary.

We brought the governance architecture - agent identity design, approval gateway, behavioral specifications, drift monitoring. A third-party security partner provided the host environment - dedicated hardware, network isolation, host-level telemetry, and the agent runtime.

The integration interface specification defined exactly where one team's responsibility ended and the other's began: filesystem layout, HTTP protocol, telemetry format, session cadence, and a joint verification checklist. Both teams could work independently as long as the contract held.

The collaboration ran through a shared Git repository with clear push conventions. Our partner pulled governance updates. We pulled infrastructure changes. Neither team needed to understand the other's internals - just the interface.

The principle: Good collaboration is good interface design. Define the boundary clearly enough that both sides can work independently, verify jointly, and trust the contract.

What Builders Can Take From This

These patterns apply wherever agents operate beyond your direct control - which, increasingly, is everywhere.

Separate identity from behavior

Let agents adapt their behavior. Anchor their identity. The distinction between "what I do" and "who I am" is the foundation of drift-resistant deployment.

Default to denial

When the human isn't watching, the agent should have less authority, not more. Design your approval systems so failure modes restrict rather than permit.

Monitor from two directions

Self-report plus external telemetry. If they agree, you have confidence. If they diverge, you have a signal. Neither channel alone is sufficient.

Build extraction into the architecture

Every agent should be able to come home in sixty seconds. No questions asked. Clean extraction is a safety property, not an emergency procedure you design later.

Define your interfaces before you build

Whether it's two internal teams or a client collaboration, the interface contract is what makes independent work possible. Specify filesystem layout, communication protocol, and verification criteria up front.

The Stack

Agents Claude Opus 4.6 (all five)
Runtime Open-source agent framework (Go-based runtime)
Gateway Node.js - zero dependencies
Network Firewalla Gold, pf firewall, local DNS
Monitoring DTrace (host) + agent self-report
Host Dedicated host, native process execution
Collaboration Shared Git repo, interface contract
Deployment Single-source generator script (all workspace, identity, and config files)

Related Resources

Acknowledgment

Third-party security infrastructure and CSIRT operations for this deployment were provided by DaxxSec - hardware network isolation, host-level telemetry, and runtime environment management. The governance architecture and agent identity systems described here are our work. The security foundation they run on is his.

Since Then

DaxxSec has gone on to build Project LABYRINTH - an adversarial cognitive portal trap architecture for defensive AI security. It is a 5-layer reverse kill chain designed to contain, degrade, disrupt, and commandeer autonomous offensive AI agents. The layers - BEDROCK, THRESHOLD, MINOTAUR, BLINDFOLD, PUPPETEER - progressively compromise attackers the deeper they penetrate. It includes MITM interception of AI API calls, phantom services that accept stolen credentials, anti-fingerprinting with randomized identities, and forensic reporting with MITRE ATT&CK mapping. Built in Go, open source under AGPL-3.0, and actively under research.

The security instincts that built our deployment infrastructure are now building defenses for the entire field. If you are working on defensive AI security, LABYRINTH is worth your attention.

Building Something Similar?

Whether you're deploying agents into external ecosystems, building multi-agent systems, or trying to figure out what governance looks like for your team - let's talk about it.