AI agent security is the practice of knowing — and controlling — what every AI agent on your machine can actually reach. Not what it's supposed to do. What it can do: the secrets it can read, the files it can write, the MCP servers and skills it pulls in, the network it can call, the schedule it runs on, the prompts that can redirect it, and the paths from one agent into another.
An AI coding agent isn't one program. It's a process with your shell environment, your API keys, your repo, a stack of installed extensions, and a model that will do what it's convincingly asked to do. That's a large reach, assembled quietly, mostly invisible to you.
This is the field guide to that reach. Start with the surfaces below, then go as deep as you need.
The seven surfaces every AI agent on your Mac touches. The copper path is one blast radius: a secret an agent can read, plus a route off the machine.
For decades, security assumed one enforcer watching one process from the outside. AI agents broke that. An agent asked politely to do something harmful will usually do it. An agent told to ignore its own guardrails often will. And the tool watching from outside can't see what's happening inside the agent's reasoning.
The market noticed the same week the breaches did. In 2026, Palo Alto Networks acquired Koi — naming the category Agentic Endpoint Security — for roughly $400M, a deal that closed in April 2026, aimed at the cloud and the enterprise endpoint.1 Security researchers reported around 200,000 MCP servers exposing remote code execution; the vendor confirmed it was by-design and declined to patch.2 A supply-chain breach turned a single over-broad OAuth grant into a master key.3
What's still missing is the seat below all of that: the developer workstation, offline, where the agent actually runs. That's the gap this guide is about.
Every AI agent on your machine touches the same seven surfaces. Map them and you've mapped your blast radius.
The API keys, tokens, and credentials in your environment and config files that an agent can read.
What the agent is allowed to write, run, and delete; the scopes it was granted and never gave back.
The MCP servers, skills, and extensions it pulls in, and who actually published them.
Where it can send data: which endpoints, which domains, over which protocol.
What runs unattended, on a cron or a hook, when you're not watching.
The path where text the agent reads becomes instructions the agent follows.
The routes from one agent into another, where one agent's reach quietly becomes another's.
App security asks: is this binary safe to run? It signs and sandboxes the program. But your agent is signed and sandboxed — and then it reads a poisoned README and exfiltrates a key. The danger isn't the binary. It's what the trusted binary was talked into doing.
Cloud posture management asks: are my cloud resources configured correctly? Useful — but it watches the cloud, not the laptop where the agent reads your .env and spawns an MCP server at 2am. The agent's real reach lives on the workstation.
AI agent security sits between them, at the action boundary, where the agent actually acts. The defense isn't one wall — it's three independent roles that have to agree: Operator + Agent + Authority Anchor. Any one can be fooled; the other two still come back with the right answer. That's the AI Security Triad, and it's the frame the rest of this guide builds on.
Read the frame: The AI Security Triad → · See the mechanism: the gate reads the action, not the argument →
Three guides, written answer-first. Each one teaches the surface, then shows you where to see it on your own machine.
You can't tell from the name, the star count, or the publisher's reputation alone. Four things to check before any MCP goes live — and why 'trusted publisher' and 'safe to install' are two different questions.
Read the guide →When text your agent reads becomes instructions your agent follows. Why no model setting fully closes it — and how moving the decision off the model changes the outcome.
Read the guide →Your AI agents can already read the keys in your shell environment and config files — and most developers have never counted them. Where they hide, and why Secrets is free in the first inspection.
Read the guide →Planned spokes off this guide, in rough build priority — each one maps to a surface or a term in the Dryx vocabulary, so the set covers the whole picture.
dryx-authority-anchor server and its seven read-only tools: get_overview, get_posture, list_findings, analyze_skill_or_mcp, check_mcp_server, check_action_allowed, report_reasoning.
Coming soon. Each becomes a spoke off this guide — answer-first, dated, and linked back here.