Trust is the Wrong Word for AI Agents. Here's the Right One.

For the last decade, security teams learned one rule the hard way: you don't trust what you download.

SolarWinds taught it to roughly 18,000 organizations that installed a routine, digitally signed update — and got a nation-state adversary in the bargain. The npm ecosystem taught it through typosquatted packages. MOVEit taught it again. None of those were malware someone clicked. They were dependencies people trusted.

The most dangerous risk was never sitting at your firewall. It was the thing you pulled in, signed off on, and trusted without ever really looking.

Now we're onboarding a new kind of dependency. And this one doesn't sit there waiting to be run. It acts.

The dependency that acts

A compromised package waits until you execute it. An AI agent — what my company calls an AI Employee — decides, chains tools, and changes its behavior on the fly. It doesn't wait to be executed. It executes.

If that sounds like a someday problem, it isn't. Last year researchers demonstrated EchoLeak: a single email to a Microsoft 365 Copilot user, no link to click, no attachment. Copilot read the email — its whole job — and a hidden instruction inside told it to find sensitive data and quietly send it out. Zero clicks from the human. CVE-2025-32711, scored 9.3 out of 10. The trusted thing on the inside did the damage.

The agents are already here. In a lot of organizations they're already opening pull requests. The only thing still up for grabs is whether they show up governed or ungoverned.

Autonomic, not autonomous — yet

Before we talk about controls, one piece of precision that cuts through most of the hype.

Most of what we're deploying today is autonomic, not autonomous. Think of the autonomic nervous system — it runs your heartbeat and your breathing. Powerful, and it runs without you thinking about it, but it isn't deliberating. That's a good description of today's agents. They execute workflows. They follow patterns learned from the past. They act. What they don't do — yet — is form their own goals or simulate the future to make a genuinely cognitive decision, the way a self-driving car has to when it decides whether to brake.

Why does this matter? Because it kills a lot of the fear. An autonomic system isn't plotting. When it fails, it usually fails by faithfully executing the wrong pattern — following a poisoned instruction, or running a task it didn't have the context for. That's a containable engineering problem, not science fiction. And it's exactly why the controls below are the right ones.

So stop saying "trust"

Here's the reframe. We keep saying we need to trust these systems. I don't think trust is the right word.

Trust is something you extend to a person — someone who reasons, who has intent, who you can hold accountable. For an autonomic system that executes a task, the right question isn't whether you trust it. It's how much confidence you have in it to do a specific, bounded job — and how you verify that. Confidence you can earn. Confidence you can measure.

That single word-swap changes how you build. You don't try to "trust" an agent into safety. You engineer confidence into it — by design.

Security by design = onboarding a workforce

The most useful frame I know for this is hiring.

You've onboarded people before. You don't hand a new employee root access on day one and hope for the best. You give them a badge, a job description, a manager for the first ninety days, and a record of what they did. An AI Employee gets the same four things.

• The badge — identity. Every agent acts as itself, with its own provisioned, auditable, revocable identity and short-lived credentials. Never a human's token, never a shared service account. Non-human identities already outnumber humans by more than 50 to 1 in most environments; you can't control an actor you can't name, or stop one you can't revoke.
• The job description — least privilege. OWASP's loudest agentic risk is Excessive Agency: the agent can do far more than its job needs, so when it fails, it fails everywhere. Scope tools and data to the role, and authorize at the action — not just the role — because agents pick tools at runtime.
• Supervision — the validation loop. The agent proposes; something verifies before it commits; and a human signs off on anything irreversible. The trap is approving everything — people rubber-stamp 400 low-risk actions and miss the one that mattered. Reserve the human for the high-blast-radius calls.
• The performance review — observability and audit. You can't control what you didn't log. Inventory your agents (most organizations can't say how many they have), log every action, and monitor continuously. Shadow agents are shadow IT with a faster clock.

The hard case: my own twin

Let me make this concrete with the hardest example I have — mine.

I run a Twin: a personal AI that works from my context, my priorities, and my access. And here's the uncomfortable part: it has the same access I do.

That seems to break the rule I just gave you. If least privilege is the goal, why does my Twin have my entire keyring?

Because least privilege exists to shrink the blast radius — and when an agent does your whole job, its work spans your whole access surface. Scope it down and you break it. So you don't shrink the blast radius at the permission layer. You shrink it everywhere else.

Security teams bucket controls three ways: preventive (stop it from being possible), detective (catch it instantly), corrective (undo it fast). Least privilege is preventive — and I can't lean on it for a full-access Twin. So I lean all the way into the other two, plus two controls that are simply non-negotiable:

1. A human gate on every irreversible action. Without it, an automated mistake is permanent.
2. Real injection containment. "Same access as me" cuts both ways — hijack the Twin and the attacker has my access. And this isn't hypothetical: OWASP found prompt injection in more than 70% of the production AI deployments it audited.

Same ceiling as me. A fraction of the freedom. Name it honestly — it's a trade, not least privilege — and it holds.

What to do Monday

If you take one thing from this, make it a starting list:

1. Inventory your agents and the non-human identities you already have.
2. Kill shared tokens — give every agent its own short-lived identity.
3. Scope tools and add one pre-action authorization gate.
4. Write a short human-approval list — irreversible actions only.
5. Log every action into the observability you already run.
6. Map your gaps to the OWASP Agentic Top 10 so you can show coverage.

And do all of it as a golden path — make the secure way the easy way, so engineers fall into safety instead of climbing over it.

Earned confidence, by design

We spent a decade learning not to blindly trust what we download. We don't have to throw that lesson away for the thing we onboard.

The AI Employee gets a badge, a job description, a supervisor, and a performance review. That's not blind trust. That's earned confidence — by design. And it means you don't have to choose between reckless adoption and standing still. You can put a synthetic workforce to work — even one with my level of access — and stay in control, because you built it that way.

Security by design isn't a brake on agentic AI. It's the only thing that lets you ship it.

This is adapted from my 2026 PlatformCon NYC talk, and expands on ideas in The AI Cybersecurity Handbook. If you're working through agent governance on a real platform, I'd love to hear how you're handling identity and the human-in-the-loop question — reply and tell me.