AI agent security best practices for the enterprise

In May 2025, researchers at Invariant Labs demonstrated how a malicious GitHub issue could lead an AI coding agent with legitimate access into moving private repository data into a public pull request, without stealing credentials or exploiting a flaw in the GitHub MCP server code itself. The problem lay in the agent workflow’s trust boundaries: the agent simply used access it had already been approved to use.

Authenticated, authorized activity can still work toward the wrong objective, and confirming that gap is where most enterprise programs strain hardest.

This piece lays out a practical framework to close it, organized around where an agent sits on its own autonomy curve.

At a glance

• Enterprise AI agent security maps to a three-rung ladder: AI-assisted, AI-orchestrated, and autonomous, each with different controls.
• OWASP, AWS, and NIST AI RMF place runtime detection on the organization running the agent; most programs strain hardest there, not on identity.
• Least-privilege credential scoping is the foundational control: agents should hold only the permissions their task requires.
• Deception-based detection produces a high-confidence signal without matching a known attack pattern, since no approved workflow should touch a decoy asset.
• In the Navy’s ANTX FY25 exercise, deception delivered 100% true positive alerts and 80% denial of attacker objectives, scoped to that exercise.

Most AI agents can be sorted by their maturity and capabilities onto a three-rung ladder. AI-assisted agents are human-supervised with a narrow scope; a person reviews each step. AI-orchestrated agents chain several actions together with low supervision; a person checks in after the fact rather than during. Autonomous agents are self-directed and decide at machine speed, faster than a person could review even if someone were watching.

Think of it like training a new employee. When they start, they check in with their boss before every move. A little later, they might do one task at a time and report back. If they excel in the role, eventually they are able to make judgment calls faster than management would have time to review.

This ladder is an editorial device, not a formal maturity model like AWS’s four-scope Agentic AI Security Scoping Matrix. It is meant to make one point clear: the risk profile changes at each rung, not just the volume of agent activity, so security controls need to change accordingly. The majority of enterprise security programs are built for the first rung and assume that coverage extends to the third. It does not.

The five practices below map across this ladder, some specific to a single rung and others load-bearing at every rung:

This mapping is illustrative, reflecting how review priorities shift as agent autonomy increases; it is not an external standard or a set of verified product capabilities.

Best practice 1: build a non-human identity inventory

AI agent credentials need records. Each one, whether a service account, API key, or OAuth token, should have a documented scope, expected behavior, and owning team: together, this is the identity inventory.

While enterprises are very good at tracking human access, they rarely take the same precautions for AI agents and service accounts. Addressing this gap is foundational and applies across all three rungs: a team cannot secure a credential it does not know exists. ShadowPlex Identity Protection supports detection across major IAM platforms, which gives a team the visibility needed to build and maintain this inventory rather than relying on a manual spreadsheet exercise.

Best practice 2: enforce least privilege for agent credentials

Do not give an agent more permission than it needs. Give it the key to the one door it needs, for only as long as it needs it, then take the key back.

Four agentic AI security controls enable this: per-task credential scoping, short-lived token issuance, secrets manager integration, and regular permission audits.

This ties to OWASP’s Excessive Agency risk category. An agent with too many permissions expands the blast radius of the most damaging misuse scenarios. Minimizing standing access will not eliminate that risk, but it shrinks it: a compromised agent with narrow permissions does far less damage than one with broad, unreviewed access.

The risk compounds as agents move up the ladder. A narrowly supervised agent with too much access is a problem worth fixing. An autonomous agent with too much access is a far bigger one: no human is positioned to catch the misuse before it compounds.

Best practice 3: instrument AI-accessible paths with deception

To catch agents operating out of bounds, deploy honeytokens: decoy credentials or data placed in the paths AI agents can reach, such as API endpoints or secrets stores. A honeytoken is a distinct kind of asset from a traditional honeypot, and it inherits none of the old complaints about honeypots being slow to deploy, easy to spot, or dependent on manual upkeep, because it is placed and refreshed automatically rather than hand-built.

360 Deception, Acalvio’s deception framework, takes this approach through ShadowPlex. It automates both deployment and refresh, so decoys stay current instead of going stale, though signal quality still depends on where decoys are placed and how consistently they are maintained. No approved workflow should ever touch a decoy asset, so any interaction with one produces a high-confidence signal of intent: why did anything touch an asset no approved workflow should require?

Deception is additive here, not a replacement for SIEM, EDR, and IAM. It is specifically aimed at the gap between where an agent is already authenticated, and acting like it belongs, and where existing tools strain. Because decoys sit outside any path a legitimate agent or user workflow would ever need, they do not interfere with production agent activity: a decoy that a real workflow could reasonably reach is a placement error, not a detection strategy.

Best practice 4: monitor agent-to-API call chains

Capture every consequential action an agent takes and analyze the sequence against what that workflow is expected to do. One anomalous API call may not prove misuse on its own; a multistep sequence across systems may only become clear after correlation. Alert on deviations from the pattern a workflow normally follows.

Human activity does not map directly onto agent activity, so agent patterns need to be built from how agents actually behave, not borrowed from user behavior analytics. Any honeytoken or decoy API access should trigger an investigation playbook, pairing the automation with a person reviewing the finding rather than waiting on someone to notice an alert on its own. This connects the practice directly to the deception layer above it.

Best practice 5: validate coverage with AI-assisted adversary emulation

Run adversary emulation exercises that target AI agent manipulation vectors, including prompt injection, supply chain compromise, and excessive agency exploitation.

Treat these as practice runs: have a team attempt to get past deception coverage the way a manipulated agent, or an attacker, might. The goal is to confirm that coverage fires on the attack paths identified, then use the findings to refine honeytoken placement and HoneyPaths configuration. Repeat the exercise on a regular cadence to keep pace with how agent workflows change.

In the U.S. Navy’s ANTX FY25 exercise, Acalvio reported 100% true positive alerts and 80% denial of attacker objectives against automated, credential-driven intrusion techniques. That result is scoped to that specific exercise and to those techniques; it is not a claim about production AI-agent deployments, and it should be read as exactly that: a strong result inside a defined test, not a blanket guarantee.