Agentic AI Is Becoming a Cybersecurity Problem
Once agents can take actions, they become non-human identities with privileges — and that turns “AI productivity” into “security surface.” This post explains the new threat model, why “kill switches” are really identity and execution controls, and the architecture patterns that make agentic systems operable.
Axel Domingues
March’s hot topic wasn’t “agents can do more tasks.”
It was the uncomfortable follow-up:
Agents are becoming a cybersecurity problem.
Not because models are evil.
Because agents are power:
- tokens that access APIs
- automations that run while you sleep
- tools that can write to production systems
- workflows that can create real side effects (emails, purchases, deployments)
- and plugins/skills that quietly expand capability
When you add autonomy to access, you create a new class of actor inside your organization:
a non-human identity that behaves like a fast intern with root access.
This article is the engineering lens:
- what changed in 2026 (why this suddenly feels urgent),
- the real threat model for agentic systems,
- and the architecture controls that keep “helpful automation” from turning into “untraceable incidents.”
I’m not teaching exploitation. I’m teaching how to design systems so that even if something goes wrong, you can contain it, explain it, and recover.
The shift
Agents turn LLMs from “text output” into privileged action — and security people notice immediately.
The new primitive
An agent is a non-human identity: credentials + scopes + budgets + auditability.
The meme that matters
“Kill switch” isn’t a feature — it’s an identity and execution control plane.
The goal
Agents that are least-privileged, sandboxed, observable, and revocable.
What changed (why March 2026 feels different)
We’ve had “AI security” discussions for years.
But agentic systems changed the economics:
- they can take actions at machine speed
- they can chain tools together across boundaries
- they can operate in places your monitoring doesn’t expect (mobile app APIs, internal SaaS)
- and they can fail in ways that look like “human mistakes,” but are harder to attribute
In short:
Agents are a third category — and most stacks don’t have a clean model for them yet.
That’s why the conversation in March shifted to terms like:
- kill switches
- agent identity
- least privilege for automations
- audit trails for tool calls
- and runtime containment
The core mental model: agents are identities with side effects
Stop thinking of an agent as “a chatbot that can click things.”
Think of an agent as a service account with a brain:
- it has credentials
- it has access scope
- it can trigger side effects
- it can be tricked by untrusted text
- it can be replayed, retried, or misconfigured
- and it can be compromised indirectly via plugins, prompts, or stolen tokens
If you accept that model, the architecture becomes obvious:
Treat agents like privileged services, not like UI features.
Mini-glossary (only the words we’ll use)
A process that interprets goals and takes actions via tools (APIs, connectors, automations). The important part is not “reasoning.” It’s side effects.
Credentials owned by software, not a person. Examples: API keys, OAuth tokens, service accounts. Agents need these — and that makes them governable.
A control layer in front of all tools that enforces allowlists, scopes, budgets, approvals, and logging.
A control that can immediately stop an agent’s ability to act: revoke credentials, terminate sessions, disable risky tools, quarantine skills, and block outgoing calls.
The sandbox / VM / container boundaries that limit filesystem, network egress, process spawning, and secret access.
The threat model: what’s actually dangerous
Security discussions get vague fast. Let’s stay concrete.
Agentic systems create risk in four predictable ways.
Untrusted text (emails, tickets, docs, web pages) can contain instructions that try to steer the agent into unsafe actions.
The fix is not “tell the model to ignore it.” The fix is policy boundaries + tool gating.
If an agent can access high-scope credentials, any bug or malicious tool call can exfiltrate them.
The fix is dedicated identities, short-lived tokens, and secret isolation.
As soon as you can “install skills,” you have the same problem npm has:
- malicious packages
- typosquatting
- hidden dependency trees
- social engineering via setup steps
The fix is allowlists, signatures, scanning, sandboxing, and provenance.
Agent activity often looks like “API-to-API automation,” not a human in a browser. That can bypass controls built around user sessions and UI patterns.
The fix is treat agent actions as first-class audit events with dedicated monitoring.
None of these are exotic.
They’re classic security problems — with a new actor that makes them happen faster and more often.
“Kill switch” is not a button — it’s a control plane
Everyone says “agents need a kill switch.”
Good instinct. Bad implementation if it’s only UI.
A real kill switch must stop capability, not just a process.
Here’s what “kill switch” should mean in an agent architecture:
Revoke identity
Invalidate tokens and service accounts immediately. Rotate credentials. Break sessions.
Terminate execution
Stop the runner: cancel jobs, terminate the sandbox, freeze queues.
Disable tools
Turn off high-risk connectors (email send, deploy, payments) at the gateway.
Quarantine skills
Block a skill/package version, isolate its runtime, and prevent re-install.
It’s how you make experimentation safe enough to deploy.
The architecture pattern: Agent Identity + Tool Gateway + Execution Envelope
If you want one blueprint, it’s this:
Component 1: Agent identity issuer (treat agents like services)
You need a way to mint and manage identities for agents:
- dedicated service accounts per agent / workflow type
- short-lived tokens with refresh constraints
- scoped OAuth apps per connector
- explicit ownership (who is responsible for this agent?)
Rule: an agent never borrows a human’s permanent identity.
Component 2: Tool gateway (the real security boundary)
All tool calls flow through a gateway that enforces:
- allowlists (which tools exist at all)
- scopes (what an agent is allowed to do)
- budgets (how many actions per time window)
- step-up approvals (humans for risky actions)
- structured logging (who/what/why)
Rule: the model is not the boundary. The gateway is.
Component 3: Execution envelope (contain the blast radius)
Run agents in an environment designed to fail safely:
- VM or container with minimal mounts
- no access to personal home directories
- outbound network allowlist where possible
- blocked access to host credentials and browser profiles
Rule: assume compromise and design for containment.
The “least privilege” checklist for agents
Least privilege is not a slogan. It’s a configuration discipline.
Define the job
Name the workflow:
- “draft reply to ticket”
- “summarize incident report”
- “open a PR with a change proposal”
If you can’t describe the job, you can’t scope it.
Grant the smallest tool set
Don’t give an agent “access to GitHub.” Give it:
- read-only repo access
- PR creation only
- no merge permission
- no org admin tokens
Use short-lived credentials
Prefer tokens that expire quickly and can be revoked centrally. Long-lived secrets are blast-radius multipliers.
Add step-up approvals for irreversible actions
Examples:
- send email to external list
- publish content
- deploy to production
- delete or export data
Put budgets on autonomy
Rate-limit:
- tool calls
- message sends
- ticket creation
- data exports
Budgets turn “oops” into “contained oops.”
Observability: the security team can’t protect what it can’t see
If you’re running agents, you need a new set of logs.
Not “chat logs.”
Action logs.
A minimal “agent audit event” should include:
- agent identity (which agent/workflow)
- tool invoked (connector name + operation)
- target resource (ticket ID, repo, channel, tenant)
- inputs/outputs (redacted where needed)
- policy decision (allowed/denied/approval required)
- human approvals (who approved, when)
- correlation ID across steps
If the actor is software, you must log it like software.“Something posted to Slack and we don’t know who did it.”
How to ship this without boiling the ocean
Most teams freeze because they imagine “agent security” as a massive program.
You can start small if you sequence it correctly.
Step 1 — Introduce agent identities
Even if it’s manual at first: separate tokens and accounts per agent.
Step 2 — Add a tool gateway
Centralize tool calls. Enforce allowlists and basic scopes.
Step 3 — Add a kill switch
Revocation + tool disable + runner cancel. Make it real, not decorative.
Step 4 — Sandbox execution
Move the agent runner into a VM/container with tight mounts and egress controls.
Step 5 — Add audit events and dashboards
Log actions, approvals, and denials. Watch the “high-risk tool call” stream.
Step 6 — Add anomaly detection later
Once you have logs, you can learn baselines and detect drift.
This isn’t glamorous — and that’s the point. Security architecture is supposed to look boring when it works.
March takeaway
Agents are not just smarter UIs.
They are new security principals.
So the winning posture for 2026 is simple:
March takeaway
Treat agents as non-human identities with privileges.
Design for least privilege, sandboxed execution, tool gateways, audit trails, and fast revocation.
That’s how you get automation without losing control.
Resources
“Kill switch” discussion (Okta)
A mainstream signal that agent identity and revocation controls are becoming executive-level security requirements.
Agent-generated app traffic
A useful framing: agents generate API-native traffic that bypasses UI-centric monitoring assumptions.
FAQ
Sometimes that’s part of the story, but it’s not the main one.
The main shift is that agents have:
- access
- autonomy
- and side effects
Even a mediocre model becomes dangerous if it can take privileged actions without strong controls.
Turning off a process is not enough.
You need to revoke the agent’s ability to act:
- credentials
- sessions
- tool permissions
- queued jobs
- risky connectors
Otherwise the agent comes back on reboot and keeps going.
Separate identities.
Give agents dedicated credentials with minimal scope. Stop borrowing human sessions. Once you do that, everything else (revocation, logging, policy) becomes implementable.
Security controls don’t have to block productivity.
Start with:
- allowlists
- budgets
- audit logs
- and approvals only for high-risk actions
Then tighten gradually as you learn where the system actually misbehaves.