The New Trusted User: AI Agent Security in Practice
AI agents are no longer just chat windows. They read documents, query databases, create tickets, send emails, write code and connect to business systems. That makes them useful. It also means AI agent security is partly an identity question, because an agent looks a lot like another user in your environment.
Not a human user, of course. But a user with credentials, permissions, integrations and the ability to take action. Like any user, an AI agent can be misconfigured, over-privileged, manipulated or compromised.
The question is no longer only “Who logged in?” It is also “What is this agent allowed to do, who approved it, and what happens if it gets it wrong?” This post reflects published guidance as of 2 November 2026.
Work is being done, and nobody is at the desk.
Your Newest Colleague Does Not Need a Desk
An AI agent has no name badge, no coffee mug and no opinion about the office thermostat. It can still have access to your email, customer records, cloud storage, development tools or internal knowledge base.
That access is usually granted for a good reason. A support agent needs to search documentation. A coding assistant needs repository access. An automation tool needs to create tickets or update records. The problem is not that these tools exist. It is that broad access is faster to grant than a careful answer to “what does this tool actually need?”
This is where the familiar principle of least privilege becomes relevant again. An agent should receive only the access a specific task requires. Not “whatever the person using it can access”, and certainly not administrator rights “just in case”.
NIST makes the same point about AI agent security. In an August 2026 blog post, it says agents need to be treated like first-class entities with their own unique identifiers, credentials and entitlements. On 27 October, it followed up with an initial set of ten design tenets for agent identity, including zero standing privilege and short-lived, just-in-time access.
A person and an agent need separate identities.
Why AI Agent Security Is a New Identity Problem
Traditional security controls were designed around people. Employees have accounts, devices, managers, approval workflows and, at least in theory, a sense of consequences.
AI agents complicate that model. They can act for a person, a team or an entire workflow. They may use an API key, a service account, a browser session or a connection to another business application. When several agents work together, responsibility gets harder to trace.
Take a simple case: an employee asks an AI assistant to “clean up the project folder”. The assistant can reach cloud storage and a project-management tool. It deletes files, moves documents, updates tasks and sends the team a summary. Helpful? Possibly. Risky? Also possibly. What if it deleted the wrong folder, shared a document in the wrong channel, or followed instructions hidden in a file it was asked to summarise? None of this needs a malicious AI. It only needs excessive access, weak boundaries and no meaningful approval step.
One of the most common mistakes is letting an agent inherit the permissions of the person using it. If an employee can export customer data, the agent can too. If that employee has administrator rights, the agent may get those as well. That turns a convenience feature into a privileged insider.
The safer approach is to separate human identity from agent identity. Microsoft’s guidance recommends treating every agent as a first-class principal: a unique, dedicated identity with a named owner and an explicit purpose, task-based roles, tightly scoped permissions and end-to-end auditability. In plain language: do not hand the intern the keys to every room because they asked where the kitchen is.
Every plugin and API is another link in the chain.
AI Tools Are Part of Your Supply Chain
AI agents rarely work alone. They depend on models, plugins, APIs, developer tools, package libraries, cloud services and third-party integrations. Each dependency is another place where credentials, code or data can be exposed.
A compromised developer credential, a malicious package or an insecure integration can affect more than one application. If an AI-enabled development tool can reach source code, deployment pipelines or cloud credentials, the damage can reach production systems.
That is why AI agent security belongs in your supplier-risk and software-supply-chain discussions. Before connecting a new tool, find out who owns it, what data it can access, what actions it can perform, where its credentials are stored and whether it really needs production access. These questions are not anti-innovation. They are the digital equivalent of asking whether the new office visitor needs a key to the server room.
Most access stays off. A few switches are on, on purpose.
Practical AI Agent Security Controls That Scale
You do not need a large security team to manage AI agent risk sensibly. Five steps cover most of it.
Make an inventory. List the AI tools, assistants, plugins and automations in use, including the unofficial ones. “Shadow AI” is usually less dramatic than it sounds, but it can still introduce unknown data flows and permissions.
Give every agent its own identity. Skip shared accounts, reused passwords and personal credentials. An agent needs a clear owner, a defined business purpose and permissions tied to that purpose. That makes the question that matters after an incident much easier to answer: what did this agent do, under whose authority, and what changed?
Apply least privilege. Start with read-only access where possible and add write permissions only when there is a clear business need. Keep high-risk actions separate: an agent that can read a knowledge base does not automatically need to delete records, export whole databases or change user permissions. Prefer short-lived access to permanent access. Long-lived API keys and standing permissions are convenient until they are not, so use task-specific credentials, just-in-time access and automatic expiry where your tools support it. When the task ends, access should end with it.
Require human approval for sensitive operations. Bulk changes, data exports, privilege changes, payments and production deployments are good candidates for a “pause and confirm” step. Microsoft recommends gating high-impact actions such as delete, export or privilege changes behind step-up approvals. NIST adds a warning: if people are asked to approve everything, they start clicking “allow” out of habit. Keep the approval list short enough that each approval still means something.
Log what matters. A useful audit trail shows which agent acted, which identity or permission it used, what it accessed, what it did, when, and whether it acted on behalf of a user. Without that context, investigating an incident becomes digital archaeology.
Know how fast you can pull the plug.
Test the Off Switch
Granting access is easy. Removing it quickly is the more useful skill, and a tested off switch is a core part of AI agent security.
Periodically test whether you can disable an agent, revoke its credentials, invalidate its tokens and stop an integration without breaking half your business processes. Microsoft’s guidance makes the same point: practise disabling the agent identity and rotating credentials the way you test any other recovery path. If an agent cannot be turned off quickly, it is not fully under control.
A revocation test does not need to be complicated. Pick one non-critical integration, simulate a compromise or misconfiguration and measure how long containment takes. The answer may be uncomfortable, but it is better to learn it in a test than during an incident.
Access that is granted on purpose.
Trust Is Not a Security Control
AI may automate tasks, but it does not remove human judgement. Employees still need to recognise suspicious requests, report unusual behaviour and avoid approving something just because a message sounds authoritative. Attackers know this. AI makes phishing and social engineering more convincing, more personalised and cheaper to produce at scale. So training should focus on practical habits: verify unexpected requests through a known channel, be wary of urgent instructions and report concerns early. An employee who says “That request seems odd, I will check” can prevent a great deal of trouble.
AI agents bring real productivity gains. But in AI agent security, trust should be earned through identity, scope, logging, approval workflows and ongoing review, not assumed because a tool is popular or its output sounds confident. The goal is not to block every AI tool. It is to know exactly what you gave an agent, why you gave it and how to take it back.
For organisations building that foundation, continuous monitoring through Managed Detection & Response powered by NovaMDR™ can help identify unusual activity across systems, while behaviour-focused awareness training through Phished can help employees recognise and report the human-targeted attacks that often come before a technical compromise. Neither replaces thoughtful access controls, but both support a security programme designed for the new trusted user.
Sources: NIST: Why Agentic AI Needs a Strong Identity Foundation, NIST: Design Tenets for Agent Identity Management Systems, Microsoft Security Blog: Least privilege for AI agents, Microsoft Learn: Least privilege for AI agents.
Reviewing which tools have access to what (AI-generated image)
This post may contain AI-generated images, graphics and/or photos.
