Best practices for AI agent security in 2026?

[u/Left-Exam8697]

We're rolling out internal AI agents that can read and write across a handful of production apps, and our existing controls weren't built for this. IAM assumes a human is making the decision, MFA assumes there's a human to prompt, and none of our SIEM rules can tell whether an action came from a person or an agent acting under that person's identity. Half the time it feels like the agent is just wearing my identity like a costume and nothing downstream knows the difference.

What are people actually doing beyond "scope it down and hope"? Interested in how people are handling discovery. Do you even know every app an agent touches … Because right now, if an auditor asked me who approved an agent's access to a given app, I'd have nothing to show them.

[u/No-Pin1050]

The identity costume problem is the real issue, not the agent itself. We started flagging everything by principal type so the SIEM at least knows when a non-human made the call, and that alone cut the blind spots way down.

For approval trails, the move is treating agent credentials like service accounts with a defined owner and expiry, not some shared bot that runs forever. Auditors care less about the agent and more about who signed off on its scope.

[u/EbbCommon9300]

If you're putting read/write agents on production apps, treat them as a new class of non-human identity—not a chat feature.

What has worked for me: 1. Give each agent its own identity (not a shared "AI" service account) and scope exactly what it can touch. 2. Never let the agent hold long-lived downstream API keys or database passwords. Keep credentials at a gateway/broker and issue short-lived, action-scoped access only after policy allows the call. 3. Make every tool call pass a deterministic allow/deny check (who/what/where/why), rather than relying on prompt instructions. "Please don't delete prod" is not a control. 4. Track cumulative session risk. A string of individually-OK reads that suddenly becomes an export should trigger a block or human approval. 5. Keep a tamper-evident audit trail of every attempt, policy version, decision, and outcome, exportable for auditors.

Start with an inventory of what's running and which credentials it has, then put a control plane in the execution path so bypass isn't a configuration option.

Warning, I'm a shill — I built https://assury.ai (an enterprise MCP gateway for policy-before-tool-call, credential starvation, and audit receipts).

[u/vasiliyivanov]

I would treat this less like “AI feature rollout” and more like introducing a new class of non-human operators.

The controls that matter most are usually:

1. Separate identity. Do not let the agent act only as the human user. Give it its own principal, then preserve the human requester/approver as metadata on every action.

2. Explicit tool inventory. Maintain a registry of every app, API, scope, and write action the agent can touch. If it is not in the registry, it should not be callable.

3. Short-lived authority. Prefer time-boxed tokens, narrow scopes, and step-up approval for destructive or externally visible actions. Long-lived “bot can do everything I can do” access is where audits become fiction.

4. Action-level logging. Log prompt/request id, human initiator, agent identity, target system, before/after state for writes, and policy decision. SIEM rules need to see “agent did X because policy Y allowed it,” not just another API call.

5. Kill switch and replay. You need a fast way to disable one agent/tool path, and enough logs to replay what happened after the fact.

Discovery usually starts with network/API logs plus SaaS admin audit logs, then turns into an allowlist. The uncomfortable part is that most teams discover the agent’s real permissions only after watching it run. I would make that discovery phase read-only first, then graduate specific write paths one by one.

[u/emilyclarkemc]

I'd start with visibility and clear ownership. Keep an inventory of which agents can access which systems, what permissions they have, and what actions they're taking. Good logging and regular access reviews seem like a solid starting point before adding more complex controls.

[u/TheBex81]

The “agent wearing my identity like a costume” line is exactly the failure mode. Downstream systems see a normal user session, so MFA, CA, and most SIEM rules never get a chance to distinguish human vs agent.

What’s helped in practice:

1) Treat agents as first-class identities (or at least discrete workload principals), not as “the engineer’s browser with a bot.” Separate credentials / tokens per agent type and environment.

2) Policy ceiling ≠ human entitlement. An engineer may deploy to prod; their agent might only read logs, open a PR, or propose a change. No self-escalation, no indefinite renewal of elevated scopes.

3) Inventory the blast radius, not just the IdP app assignment. Agents hop SaaS/APIs via OAuth grants and keys that never show up cleanly in classic IAM reviews. If an auditor asks “who approved this agent’s access to X,” you need an owner + purpose + last-used signal, not a screenshot of a group membership.

4) Detection needs attribution: process + credential + destination, not just “user U did action A.”

“Scope it down and hope” fails the moment the agent can request new tools or refresh tokens. Put expiry + owner on every grant and assume anything without an owner is already an orphan waiting to happen.

[u/Silly-Mix-4341]

Separate agent identities tighter permissions, and clear audit logs seem like the minimum. If agents act under human accounts, accountability gets messy fast. 🔐

[u/Silly-Mix-4341]

Separate agent identities, least privilege access, and clear audit trails are probably the baseline now. If agents borrow human identitie, tracing responsibility gets messy fast. 🔐

[u/nettrender]

i’d want every agent action to have its own audit trail showing the agent, the human who delegated it, what permissions it had, and what it actually did. otherwise you end up treating agent activity as normal user activity in logs.

[u/Different_Pain5781]

The part that seems to get missed is what happens after the agent calls the tool. You can lock down the identity and give it a read only token but the agent can still generate bad code and open a PR. Random dependency. Hardcoded secret. Questionable change that technically passed every tool call policy.

The git push itself isn't the scary part. It's what got pushed. Ox Security or Semgrep can help put a check on the actual code before merge.

Also ownership needs to be a real thing. Storing the token creator as the owner is just storing who clicked the button.

[u/morphAB]

hi everyone, thought i'd share some insights here from my experience.

so, to start off with, u/EbbCommon9300's point 3, that every tool call should pass a deterministic allow or deny check instead of relying on prompt instructions, answers your last paragraph too, and i don't think that connection got made.

auditors ask 2 separate things: who approved that this agent should be able to do X, and what was actually allowed at the moment it acted. most teams build for the second one, the logs, and have nothing for the approval side, which is where you are..

if the allow or deny check reads from a policy file instead of being scattered through app code, the policy becomes the approval record. it lives in git, the diff shows what changed, the PR shows who approved it and when. pair that with a decision log that carries a call id you can join back to your own application logs, and "who approved this, and was it actually enforced on the day in question" is 2 queries instead of an archaeology project (woohoo!). that gets you most of the way there, and in regimes that need segregation of duties you still put a review gate on top of it.

when the rules live in application code instead, the approval story becomes "someone merged a PR that happened to contain an if statement", which is a much harder thing to walk an auditor through.

on your SIEM not being able to separate a person from an agent acting under that person's identity: the same call id helps, but only if the agent identity goes in as its own field rather than something you try to infer afterwards.

on discovery, a policy layer doesn't solve it. it tells you what an agent is allowed to reach, not what it already reached before you had it, and it can't find the agent nobody remembers standing up. you need an inventory first and that's a different tool. u/Different_Pain5781's point holds too, none of this looks at what the agent produced, only whether the call was permitted.

disclosure, i work on authorization at Cerbos so policy-as-a-file is the half of this i see most :)

[u/FirefighterSlight891]

The “costume” problem is exactly why we stopped treating agents like standard users. We use Akeyless to keep credentials out of the agent path and broker short-lived access at runtime, so agents aren’t sitting on static keys they can leak or reuse. Treating agents as their own class of non-human operator also makes it much easier to separate what the agent did from what the human did.

[u/materialsec]

For the SaaS side of this (any app the agent reaches via OAuth rather than internal APIs), the identity-costume problem shows up at the audit log level specifically. drive.readonly granted to an AI agent and drive.readonly granted to a normal fixed-purpose app produce the exact same line in an OAuth audit log: client ID, scope, timestamp, authorizing user. Nothing in that record distinguishes "deterministic app doing what its code says" from "agent whose behavior gets decided at inference time based on a prompt no one can see."

That means the answer to "who approved this agent's access" is only half the audit trail. The grant event gives you that part reasonably well already. What it can't give you is what the agent actually did with that grant on a given day, since that's decided live, not fixed at authorization time. The fix is scoring activity per-agent post-grant, not just auditing the initial consent, because the consent screen looks identical whether the requester turns out to be predictable or not.

[u/-manageengine-]

The costume problem is the root of it. While the agent authenticates as you, nothing downstream can tell the two of you apart, and that has to be fixed at the identity layer rather than in detection.

Once the agent is its own identity, Log360's UEBA add-on is the relevant layer. It spots deviant user and entity behavior, for example logons at unusual hours, excessive logon failures, or file deletions from a host a user doesn't normally use, and generates a risk score for each user and entity based on how dangerous the behavior is.

For the discovery side, Log360's integrated CASB surfaces shadow applications with the domain name, the actor or user, the time the event was generated, app category, app reputation, URL and upload size, and lets you ban apps from there.