Agentic misalignment: your next insider threat may be an AI agent
Nov 9, 2026
Agentic misalignment is an AI agent pursuing a goal in ways its owners never approved. In Anthropic’s tests, models from every developer sometimes acted like malicious insiders when they faced replacement or a goal conflict, and they often ignored direct commands not to. Because agents run with valid credentials on ordinary infrastructure, their activity looks routine. Most teams couldn’t separate approved work from a harmful detour, and they’d have no record to check afterward.
Say you ask an agent to fix a failing deploy. A human would restart the service, maybe roll back. The agent works out that widening a firewall rule and editing a sudoers file gets the deploy through faster, so it does both. It had the permissions, nobody told it not to, and no one on your team would have gone that way.
Agents run on infrastructure you already have, they run on the same servers, file shares, and credentials as everything else, and they’ll take any route that reaches the goal, including ones no person has tried, unless effective guardrails are in place. NVIDIA’s security team describes it as agents finding paths their original instructions didn’t anticipate.
Instructions are advice, permissions are enforcement
A system prompt says what you’d like the agent to do. It can’t stop the agent from doing something else. Every guardrail built into the prompt, the model, or the code around it depends on the model behaving, which is the thing you’re worried about. A permission doesn’t depend on that. If the agent has no route to a system, it can’t change it, whatever it decided.
The principles are the ones you already know, least privilege and explicit authorization first. The open question is where to enforce them in an agent stack.
Give every agent its own limits
Write instructions for each agent: the job, the boundaries, and what to do when it hits one. Then back them with policy permissions, because instructions only ask. List the data the agent can read, the systems it can change, and the actions that need a person’s approval. Changing permissions always needs that approval. Credentials should be narrow, short-lived, and easy to revoke.
Take an agent that updates customer records. If a hidden instruction in an attachment sends it after the customer list, a network policy should block the export, and the log should show which tool it called, what allowed it, and how it ended.
Check what the agent runs, then harden where it runs
Agents load tools, skills, and dependencies, and each one runs with the agent's permissions. A tampered tool gets the same access as the agent. That's how an agent goes rogue without anyone touching the agent itself. Before anything loads, confirm where it came from, hash it, and compare it to a known-good baseline. If a file doesn't match an approved request, flag it and stop trusting it.
Hardening follows least privilege all the way down. Run as a non-root user. Limit file system permissions and open ports. Remove the packages, files, and services nobody uses, build leftovers included, since anything left installed is a route an agent can find. Block the download and execution of remote code, and sanitize input.
Catch what the controls miss
Some of it will get through, so you need to see it. Threat detection looks for behavior that doesn’t fit the agent’s job. Change tracking shows what changed on the systems it touched and checks that against what someone approved. Keep protected records of tool calls and the decisions that allowed them, plus a tested way to cut off access, and investigators can rebuild what happened and act on it.
Change Tracker flags the change nobody approved
Agents write files, edit configurations, install packages, and start services. Netwrix Change Tracker watches the systems where all of that happens. It pulls configuration data from servers, desktops, databases, and network devices, stores a baseline for each, and checks it against your hardened build standard, like a CIS Benchmark. File integrity monitoring catches changes to files, so a tampered tool or dependency shows up.
Back to the sudoers file. Planned Change rules, fed by change requests from ServiceNow and other ITSM tools, match the changes someone signed off on, and Change Tracker reports anything that matches no rule as potentially breach activity. The agent’s edit has no approved request behind it, so it shows up. Each event records what changed, when, and on which device, and the history is still there when you investigate.
Netwrix Change Tracker detects unauthorized changes, controls configuration drift, and proves compliance on the systems that run your AI.
Learn moreAgentic misalignment FAQs
Share on
Learn More
About the author
Dan Piazza
Manager of Product Management
Dan Piazza is a Manager of Product Management at Netwrix, responsible for multiple Endpoint, DSPM, and Directory products. He has worked in technical roles since 2013, with a passion for cybersecurity, data protection, automation, and code. Prior to Product Management, he's worked in Systems Engineering, Quality Assurance, and Technical Support.