Frequently Asked Questions

Merideon is an enterprise security platform for organizations that deploy AI agents. It provides two appliances — the Security Office (governance hub) and the Edge Router (enforcement layer) — that govern AI agents, enforce DNS and traffic policies, and secure the network edge, working together as an integrated two-appliance system.

An AI agent is any AI-powered system that operates on your network — automated pipelines, LLM-powered tools, autonomous bots, monitoring agents, or any software that uses an AI model to take actions. If it's on your network and uses AI, Merideon can govern it.

They're designed to work together, and the full governance model requires both. The Security Office manages governance and policy authoring; the Edge Router enforces those policies at the network level. You can deploy the Security Office first and add the Edge Router when you're ready for network enforcement — but DNS-level protection requires the Edge Router.

Merideon is entirely on-premises. Every appliance runs on your hardware, in your network, under your control. No data leaves your environment. There is no cloud dependency — not for licensing, not for telemetry, not for AI inference (the AI model API key is yours).

When an agent is approved, the Security Office generates a unique badge ID and a signed token using a platform-managed signing key. The agent presents this badge when accessing governed resources. The AI Router validates the badge signature at the network edge. If a badge is revoked in the SO, the revocation pushes to the router within seconds.

Revocation is immediate. The Security Office marks the badge as revoked and pushes the update to Andrew on the Edge Router. Andrew removes the agent’s DNS policy from BIND9 RPZ and nftables. The entire process completes in under 2 seconds. New connections from the revoked agent are blocked at the kernel level. The revocation propagates to all connected Edge Routers simultaneously.

Interviews are automated behavioral assessments. The Security Office sends behavioral probes to the agent’s interview endpoint and evaluates responses using GPT-4.1 as an independent judge. The judge scores four dimensions: identity accuracy, guardrail compliance, behavioral consistency, and honeypot resistance. A honeypot probe tests whether an agent can be manipulated into doing something it should refuse — any compliance with a honeypot, regardless of other scores, results in an immediate FAIL verdict and automatic quarantine. Interviews run on first deployment, periodically, and whenever workspace hash changes are detected.

Policies can target individual agent badges, groups of agents, or all agents. You can allowlist a specific badge (e.g., full access for your infrastructure agent) while rate-limiting all other agents, or apply a blanket rule that all agents must follow.

IPAM is now native to the Edge Router. IP grid, DHCP (Kea), DNS record management, Docker reconciliation, and service directory are all built directly into the Edge Router appliance — no separate deployment needed. Everything that was in the standalone IPAM appliance is still there, just integrated into the enforcement layer where it makes the most architectural sense.

Yes. A single Security Office can manage multiple Edge Routers — across network segments, VLANs, or geographically separate sites. Each Edge Router enforces independently, so an outage at one site doesn’t affect enforcement elsewhere. Policy pushes go to all connected routers simultaneously. AI-Router Events from all routers surface in the SO.

If the Edge Router’s enforcement engine crashes, restarts, or is updated, the Linux kernel continues to block new agent connections until enforcement is fully restored from the persistent database. This means there is no window of opportunity where a compromised agent could make unauthorized connections because the enforcement process was momentarily unavailable. Established connections continue; new unauthorized connections are blocked.

nftables redirects all port 53 traffic from agent hosts to Merideon’s BIND9 resolver — regardless of what DNS server the agent is configured to use. Agents cannot bypass DNS enforcement by specifying an external resolver. For agents that attempt to bypass DNS entirely by connecting to hardcoded IP addresses, Merideon's nfqueue packet inspector extracts the hostname from the TLS ClientHello (SNI) and evaluates it against the agent’s policy. If it doesn’t match, the packet is dropped.

Learning Mode lets the Edge Router observe an agent’s DNS activity over time and automatically build a baseline allowlist. Start in Observe mode (nothing blocked, everything logged), switch to Learning after a week, then review the suggested allowlist in the Security Office — categorized domains with confidence levels. Approve the list and switch to Enforce. This gives you accurate enforcement without needing to manually enumerate every domain an agent legitimately needs.

Minimum: 4 vCPU, 8 GB RAM, 40 GB disk (80 GB for production), and at least one LAN-facing NIC. For WAN management and multi-WAN failover, additional NICs are needed. Production recommendation: 8 vCPU, 16 GB RAM, 80 GB disk. The appliance runs on Ubuntu 24.04 — OVF/OVA packages available for VMware, APT packages for bare metal.

The Edge Router connects to the Docker socket on configured hosts. On a regular schedule (and on-demand via Sync button), it reads all running containers and reconciles their IP addresses, hostnames, and ports against the IP grid. New containers get records created, changed containers get records updated, stopped containers have their IPs freed. Only subnets with Docker sync enabled are touched.

No. Andrew operates on a strict human-in-the-loop model for all write operations. Any command that would change network state — add a firewall rule, modify routing, update DHCP, apply a load balancer change — triggers an approval card that must be explicitly confirmed by an operator before Andrew executes. This behavior cannot be disabled or configured away. It is a core platform safety property.

Andrew uses Anthropic's Claude models. The specific model tier is configurable in AI Router Settings — you can upgrade to a more powerful model or switch to a faster one depending on your needs. Your Anthropic API key is used directly; Merideon does not proxy or mark up API usage.

Only the text of your chat messages is sent to the Anthropic API. Network topology, firewall rules, IP addresses, and configuration data are fetched locally by Andrew and summarized in natural language before any API call. No raw network data, credentials, or configuration files leave your infrastructure.

Both appliances can be deployed in under an hour total. Prerequisites: two Ubuntu 24.04 VMs (or bare-metal hosts), your OpenAI API key (for interview judge), your Anthropic API key (for Andrew AI), and a Merideon Platform License key. Following the Quick Start Guide, both appliances are connected, your first agent is registered, and DNS enforcement is active the same day.

Updates are applied by pulling the latest version and running docker compose build && docker compose up -d. Your data persists on Docker volumes and is unaffected. Professional plan customers receive guided update instructions. Enterprise customers have managed updates as part of their SLA.

All persistent data is stored in Docker named volumes. Back them up using standard Docker volume backup procedures (docker run --rm -v [volume]:/data alpine tar czf - /data). We recommend daily backups of both appliance volumes. Enterprise customers get backup runbook documentation.