Why are guardrails not enough to secure AI agents?

Prompt filters and output checks are probabilistic and can be bypassed through prompt injection. What an agent can actually do is limited only by the credentials and permissions it holds, so access control is the reliable boundary.

Should an AI agent use my personal access token?

No. Give each agent its own identity, such as a GitHub App, service account or OAuth client, with short-lived scoped tokens. That limits the damage if it misbehaves and gives you a separate audit trail.

What is shadow AI in the context of agents?

It means agents and integrations that security teams don't know about, usually visible only as OAuth grants, API keys or service accounts. You find them by listing non-human identities and flagging any without an owner or recent use.

Securing AI Agents: 5 Identity Controls for Teams

In March 2026, Token Security CEO Itamar Apelblat published a sponsored column on BleepingComputer arguing that AI agents should be secured mainly through identity and access control, not prompt guardrails. It is a vendor opinion piece, not news, but the main point is right and it applies to engineering teams, not just CISOs. An agent can only do what its credentials allow. Below, each of the five recommendations is translated into controls you can actually implement.

What happened

The column, labelled "Sponsored and written by Token Security" and published on 17 March 2026, makes five recommendations: treat every agent as an identity, put access control ahead of guardrails, remove shadow AI by discovering non-human identities, scope permissions to the agent's intended purpose, and govern the agent lifecycle from creation to decommissioning. It cites no data. These are design principles, not findings. The same ideas appear in the OWASP Top 10 for Agentic Applications, published in December 2025, which lists excessive agency, tool misuse and identity and privilege abuse among the main risks.

Who is affected

Teams running coding agents (Claude Code, Codex CLI, Cursor agents) with access to repositories, CI or cloud credentials.
Teams building internal agents that call production APIs, SaaS tools or databases, including through MCP servers.
Platform and security teams that own IAM, secrets management and audit logging, because agents add a new kind of non-human identity to everything they already manage.

What it means for developers and engineering teams

Guardrails aren't a security boundary. Prompt filters and output classifiers are probabilistic. Prompt injection from a web page, an issue comment or a tool result can push an agent off its task. The only hard limit is what its credentials can reach. A coding agent holding a personal access token with org-wide repo scope can push to every repository that user can, however well it was instructed.

Agents tend to inherit human permissions. The easiest setup is to let the agent use the developer's own session, CLI login or .env file. That gives the agent everything the human has, with no separate audit trail. Logs show "alice deleted the bucket", not "the agent acting for alice deleted the bucket".

Purpose-based scoping is just least privilege applied per task. An agent that triages issues needs read access to issues and write access to labels, not admin:org. Writing the agent's purpose down in plain words makes over-permissioning obvious in review.

Lifecycle is where credentials accumulate. Agents are cheap to create and easy to forget. Each one leaves behind OAuth grants, API keys and webhook secrets that keep working until someone revokes them.

What to do now

Give each agent its own identity: a dedicated service account, GitHub App or OAuth client per agent, with a named human owner recorded in its metadata or tags. Don't let agents share a human's tokens.
Use short-lived, scoped credentials: OIDC workload identity in CI, GitHub App installation tokens (valid for one hour) instead of PATs, and cloud roles with session policies. For MCP servers, use the OAuth-based authorization in the MCP spec rather than static keys.
Write the agent's purpose down and derive permissions from it. Keep a short manifest per agent (purpose, systems, actions, data classes) in the repo, and review permission changes in pull requests like any other code.
Require a human for destructive actions: deletes, IAM changes, production deploys and payments should go through an approval step the agent can't approve itself.
Find shadow agents: list OAuth grants in Google Workspace or Entra ID, GitHub App and PAT inventories, and cloud access keys. Flag anything that has no owner or hasn't been used in 30 days.
Log agent actions as the agent: make sure audit logs record the agent identity and the human who started it, and send them to your SIEM.
Decommission properly: when an agent is retired, revoke its tokens, delete its service account and remove its webhooks in the same change.

Securing AI agents: five identity controls engineering teams can apply now

What happened

Who is affected

What it means for developers and engineering teams

What to do now

Related on TechLogHub

Sources

Get the next deep dive in your inbox

See what launched this week

The weekly digest