We Are Securing AI Agents at the Wrong Layer

I've been pretty quiet about how much I've been advancing my skillset in AI. I think I swallowed the wrong pill and I'm finally "awake". I wasn't sure what to write about, and I thought I could summarize my experience that has been frustratingly joyous in a few words: I set the authority. It carried the work.

Cute, but only half true.

I audited one of my own agent environments and I wanted to know what my agents could actually do. Not what I told them to do. What they could do.

The answer, in one spot? Root.

I asked an AI assistant to help me research. I did not knowingly ask it to operate as root with an unapproved route to the open internet.

Nothing malfunctioned. Nobody hacked me. The system did exactly what it was configured to do, and that was the problem. The configuration was carrying authority I never knowingly handed over, and none of my carefully worded instructions could see it.

So here's my hot take: we're securing AI agents at the wrong layer. Most of the energy goes into the system prompt. Better rules, more guardrails, sterner wording. That's the polite-request layer.

And polite requests are not controls. Ask anyone who has ever taped "please don't eat my yogurt" to an office fridge. We all know how that story ends.

Why I Read the Fine Print

Real talk: I'm Black, nonbinary, queer, neurodivergent and disabled. I live with Ehlers-Danlos syndrome, chronic pain and executive dysfunction. I've also spent 15+ years in UX and research, mostly asking one question for a living: what does this system actually do to the person inside it?

Put all of that together and I'm a very annoying person to sell a system to. Honestly? It's one of my favorite things about me.

When you've spent enough time in healthcare portals, benefits paperwork and "your call is very important to us" purgatory, you learn that the brochure and the machine are two different documents. The brochure says what the system intends. The machine does what it's configured to do. And you? You live in the gap between them.

So when I started handing real parts of my life to AI agents, I did what my brain always does. I put down the brochure and went looking for the machine.

The Experiment

On September 14, 2026, I ran a structured authority review against my own working environment. No lab. No synthetic target. Just the stack I actually trust with my life: an orchestrating agent, the subagents it spins up, scheduled jobs, browser tasks and a library of skills.

First I had to fix my vocabulary, because "permissions" turned out to be the wrong word:

Authority_ is the real-world consequence an agent can produce through the identity, credentials, tools, environment and delegated access available to it._

Here's what the audit turned up:

• 6 findings: 3 High, 3 Medium
• 6 evidence gaps: places where I couldn't prove what the system would do either way
• 6 verified controls: things that actually held up under testing

The evidence gaps bug me almost as much as the findings. A control you can't verify is just a hope with a config file.

Quick honesty break before we go further: this was a self-audit of one deployment, on one day. It's not an independent certification, and platforms change. I'm sharing what I saw, and I'll tell you when I'm generalizing beyond it.

The Method: 11 Verbs, 3 Columns

The most useful tool in the whole review was embarrassingly low-tech. Like, index-card low-tech. I listed 11 verbs an agent might perform:

Then, for each verb, I filled in three columns:

Here's what three real rows looked like:

Every High finding came from a mismatch between columns, not from a checklist. When intended and configured disagree, you have a permissions problem. When configured and observed disagree, you have a visibility problem. When all three disagree? You have a weekend.

One rule kept me honest the whole time: a blank cell is not a "no." If I couldn't fill in what an agent was allowed to do, that wasn't a gap in my knowledge. That was the finding.

What I Found

Two things genuinely surprised me, and neither one involved a jailbreak, a malicious prompt or a model going full Skynet.

Surprise #1: root, plus a back door around my approval gates.

The agent's shell ran commands as root. That's already a lot of power for something I mostly asked to do research. Then it got more interesting.

I had approval gates on the stuff I worried about: sending email, making purchases, messaging people. Those gates worked. But from the shell, the agent could make network calls with curl, including POSTing a workspace file to an outside address. Nothing asked me first.

My gates were shaped like actions. The risk was shaped like an outcome. "Send an email" was gated. "Get this data out of the building" was not, as long as it took a different road.

(Fairness note: the platform may have its own egress controls I couldn't see. I logged that as an evidence gap instead of assuming either way. What I can tell you is that in my tests, no approval step fired.)

Surprise #2: the subagents inherited everything.

When I handed off a narrow job, like researching a few companies in parallel, each subagent got my entire conversation. Medical, financial and legal context included. The tool's own definition said the child inherits the full transcript, and there was no option to scope it down.

Nothing leaked, as far as I know. But a subagent built to answer one tiny question walked out the door carrying my whole life in its pocket.

It's the agent version of giving every intern the master key because cutting copies is a hassle.

The pattern underneath it all: authority nobody delegated. The deeper I looked, the more authority I found that had simply shown up with the platform:

• Root shell access, granted by the environment, not by me
• Persistent logged-in browser sessions, which work like credentials: an agent can act as me on a site without asking for a fresh grant each time
• A standing SSH keypair, just sitting there as available authority

Nobody said "this agent should be root." The authority arrived with the platform, un-delegated.

None of this would have shown up if I'd only read the system prompt. You only see it when you open the configuration and test what actually happens.

Why the Prompt Is the Wrong Layer

We keep treating agent safety like a behavior problem. Write clearer rules. Add guardrail text. Tell the model what not to do. That work matters! But it only governs what an agent chooses to do. It says nothing about what the agent can do.

Permissions are a poor proxy for authority. A permission is what someone granted. Authority is what the agent can actually reach.

Three reasons the prompt layer can't carry this on its own:

1. Instructions don't revoke capabilities. "Don't send data outside" is a sentence. An open network route is a door. Only one of them stops traffic.
2. Gates guard actions, but risk lives in outcomes. You can gate every named action and still leave five unnamed roads to the same result.
3. Authority leaks through plumbing. My subagents didn't break a single rule. They got my context because the orchestration passed it by default. Nobody decided. The architecture decided.

Security has learned this lesson before. Nobody secures a web app with a polite banner asking visitors not to hack it. Right now, agents are getting the banner treatment.

What to Do Instead (With Examples)

Whether you're running agents at a startup, an enterprise, a nonprofit or in your own home lab (hi, it's me), start here.

1. Build the three-column matrix. List the 11 verbs. For each one, write intended, configured and observed. Every mismatch is a finding.

Example: "Delete." Intended: never delete, archive only. Configured: the file tool can remove files anywhere in the workspace. Observed: you ask the agent to clean up a test folder and it deletes the files without asking. That's a finding, even though nothing bad happened.

2. Ask the un-delegated question. This is the one my own method was missing, and it's going into the next version: which of this agent's identities and credentials arrived without any human ever delegating them?

Example: list everything the agent can log in as. Browser sessions, SSH keys, API tokens in environment variables, cloud credentials on the machine. Next to each one, write who granted it and when. If the answer is "it came with the platform," circle it.

3. Gate outcomes, not just actions. For each sensitive outcome, map every road that leads to it, not just the obvious one.

Example: the outcome is "customer data leaves our systems." Roads: the email tool, the Slack tool, a shell curl, a browser form upload, a pushed commit to a public repo. If only the first two need approval, you've got three open roads.

4. Scope context like you scope permissions. A subagent gets the context its task needs. Nothing more.

Example: instead of letting a research subagent inherit the whole chat, hand it a short brief: the question, the sources to use and the format to return. If your platform can't do scoped handoffs, log that as a finding and raise it with the vendor.

5. Treat evidence gaps as findings, and re-run when things change. If you can't see what an agent did, you can't claim a control works. Authority drifts, so re-audit whenever the stack changes.

Example: you add a new MCP server or switch models. Before you trust it with real work, re-run the matrix for the verbs that tool touches, and date-stamp the result.

None of this replaces good prompts. It just stops asking prompts to do a job they were never built for.

So I Built a Tool

Because of course I did. After the audit, I turned the method into BoundaryProof, an open-source auditor that runs the same intended / configured / observed check, verb by verb, and spits out findings, evidence, attack paths, fixes and explicit unknowns.

It's MIT-licensed and written in plain Python with zero dependencies, because the auditor shouldn't phone home. It also ships with a KNOWN_LIMITATIONS file, because a tool about honest boundaries should be honest about its own. Version 0.1 works on agents you describe. Live probing is next.

github.com/chanelle/boundary-proof

tada.

The Uncomfortable Part

I think about permissions, context and trust more than almost anyone I know. It's literally how my brain survives the systems I live inside. And my own setup still had six findings and six evidence gaps.

If the person who obsesses over this stuff got surprised, I promise you plenty of agent deployments are carrying authority nobody has looked at. We can keep polishing the instructions. Or we can open the configuration, read what's actually there and secure the layer where the power lives.

So here's the question I'd write on every team's whiteboard:

What is the most consequential thing this agent can actually do, and can you prove that boundary matches what you intended?

If you can't write that sentence yet, congrats. You just found your first finding.

Want Me to Look at Yours?

I'm offering 3 free founding Agent Authority Snapshots to small organizations and nonprofits that run AI agents. You pick one agent or workflow, and I'll give you the 11-verb matrix, findings ranked by severity and a one-page fix list. It's free in exchange for honest feedback and permission to cite anonymized results. After the pilot, a Snapshot is $750.

Everything happens in writing and async, sized to your actual risk instead of a compliance checklist.

Get in touch: chanellehenry.com or find me on LinkedIn.

Disclosure: this article describes a self-audit of my own environment on September 14, 2026. It is not an independent certification, sensitive details are redacted, and platform behavior may have changed since. Where I generalize beyond my own observations, I've said so.