Your Next Insider Threat May Not Be Human
Quick Answer
An AI agent does not need malicious intent to become a security problem. If it has legitimate access to company information and permission to act, mistakes, manipulated inputs, compromised credentials, or excessive authority can produce harmful outcomes.
Agentic AI security means controlling what an agent can access, what it can do, whose authority it uses, and how the business monitors and stops it. Connected AI agents need defined identities, accountable owners, limited permissions, enforced approval gates, protected credentials, activity records, and lifecycle management.
For most of this series, we have been looking at AI from the outside.
We looked at why some of the people building advanced AI systems have become concerned about where the technology is heading. We examined how an AI system could resist interference without needing consciousness, fear, or a human desire to survive. And in the last article, we explored experiments in which researchers observed models crossing boundaries under carefully constructed conditions.
Now put the AI inside your company.
Give it an identity. Connect it to Microsoft 365. Let it read email. Give it access to SharePoint, OneDrive, your customer relationship management system, financial information, customer records, and internal documents.
Then give it permission to do something.
At that point, the discussion changes. You have a cybersecurity and governance problem with immediate business consequences.
A chatbot can suggest a response to a customer. A connected agent may send it. A chatbot can explain an invoice. An agent may update the accounting record or initiate another workflow.
The distinction matters because your company has delegated authority. You need to know exactly how much.
Your AI Doesn’t Have to Become Malicious
The easiest way to misunderstand AI risk is to imagine that something dramatic has to happen first.
The AI becomes conscious. It develops its own agenda. It decides humans are the enemy.
None of that needs to happen for your company to have a serious security problem.
An agent could expose confidential information because it misunderstood who should receive it. It could modify a record based on an ambiguous instruction. An attacker could place malicious instructions in an email or document the agent processes and influence what it does next.
OWASP identifies this last problem as indirect prompt injection: instructions reach the model through external content rather than an authorized user’s direct request. The material your agent reads can become part of an attack. genai.owasp.org
OWASP also describes excessive agency, in which unnecessary functionality, permissions, or autonomy enable damaging actions when a model produces unexpected or manipulated outputs. genai.owasp.org
No evil AI required.
The ingredients are much simpler:
Access + capability + insufficient controls.
Imagine an agent reviewing vendor invoices. Reading an invoice should not give that invoice the authority to change your payment rules. Yet if the agent can interpret instructions from the document and change banking details without independent validation, a routine workflow has become a route to financial loss.
The agent may be using valid credentials throughout. That does not make the action appropriate.
Agentic AI Security Starts With Access and Authority
Security teams already understand the basic model.
An employee receives an identity. That identity receives permissions. Those permissions determine which files, applications, mailboxes, and systems the employee can access. Administrators review access, monitor activity, and remove permissions when the person’s role changes or employment ends.
A connected AI agent also operates through an identity and an effective set of permissions. It may use its own credentials, act on behalf of a user, or rely on an application’s access.
Microsoft Entra Agent ID formalizes agent identity management. Microsoft’s guidance distinguishes a business sponsor accountable for the agent’s purpose from a technical owner responsible for administration. It also recommends distinct agent identities and secure credential management. learn.microsoft.com
That gives business leaders a useful starting point.
Before asking how intelligent the agent is, ask:
What can it access, and what can it do?
Then ask who approved that authority.
The answers should be documented before the agent begins operating on important company systems.
Ten Controls for AI Agents Inside Your Business
- Give Every AI Agent Its Own Identity
You would not want five employees sharing the same administrator account. Do not build the AI equivalent.
An agent operating through someone’s personal account or a broadly shared credential creates an accountability problem. If something happens, you need to distinguish an employee’s action from an agent’s action, another application’s activity, or misuse of the credential.
Give each production agent a separate, traceable identity where the platform supports it. Record its business purpose, sponsor, technical owner, connected systems, approved permissions, and shutdown procedure.
When an agent acts on behalf of a user, record both the user and the agent involved. Borrowed authority still needs accountability.
For a small organization, the business sponsor and technical owner may work closely together. Their responsibilities should nevertheless be explicit. The sponsor approves the purpose and business boundaries. The technical owner maintains the integration and its controls.
Assign backup coverage so a departure or absence does not leave the business unable to manage the agent.
If nobody owns an agent, nobody owns its risk.
- Apply Least Privilege to AI
An agent should receive only the information, tools, and permissions necessary for its approved job.
If it needs one SharePoint site, do not automatically give it every site. If it needs to read customer records, do not assume it should delete them. If it prepares invoices, do not assume it should approve payments.
Microsoft’s least-privilege guidance recommends reviewing an agent’s combined permissions across tools and downstream systems. A narrow permission in one application can still become part of a much broader chain of access. learn.microsoft.com
Consider what the complete workflow permits. Can the agent retrieve confidential information from one system and send it externally through another? Can it change a record that triggers a payment or another automation?
The question is:
What is the minimum access required for this AI to do its approved job?
Document that answer. If the business later wants more functionality, review the additional authority as a deliberate change.
Convenience should not quietly become permission.
- Separate Reading From Acting
Businesses need to distinguish AI that can see information from AI that can change something.
Reading a calendar differs from canceling meetings. Summarizing invoices differs from initiating payment. Preparing an email differs from sending it under an executive’s authority.
Read-only access can be a sensible starting point, but it still requires boundaries. An agent that reads sensitive information may disclose it through an answer, a summary, an export, or another connected tool.
For each integration, identify the permitted actions separately: read, create, update, send, export, delete, or administer.
For example, an agent helping with customer follow-up might initially draft messages for review. Permission to send those messages should be a separate decision. Permission to change customer contact details or export the customer database should be separate again.
Test the workflow against its actual permissions. A reassuring description in a product demonstration does not establish what the deployed integration can do.
- Put Approval Gates in Front of High-Impact Actions
Some actions should require a human decision.
Examples include sending money, changing bank information, deleting substantial amounts of data, disclosing confidential information externally, granting access, changing security controls, or accepting contractual commitments.
You do not need a person approving every routine step. That would defeat much of the value of automation. Define thresholds based on the consequence, reversibility, sensitivity, and scale of the action.
A crucial distinction: telling the agent to ask permission is not the same as enforcing an approval gate.
The connected application or workflow should prevent the action until the required authorization exists. OWASP recommends enforcing authorization in downstream systems and requiring human approval for high-impact actions. genai.owasp.org
The approver should see the proposed action, affected information, recipient or destination, and relevant supporting evidence. Approval without enough context can become another automatic click.
Define an alternate approver and what happens when nobody responds. For consequential actions, silence should not count as permission.
The goal is controlled autonomy.
- Protect the Agent’s Credentials
An agent needs some way to authenticate to business systems. That makes its credentials valuable.
Passwords, API keys, authentication tokens, certificate private keys, and other secrets should not sit casually inside prompts, documents, or files the agent can expose.
Prefer authentication methods that reduce stored secrets where the platform supports them. Keep necessary credentials in an appropriate secrets-management system, limit who can retrieve them, and establish a rotation process.
Microsoft recommends managed identities or certificates for production agents rather than relying on client secrets, along with separation between environments and appropriate authentication flows. learn.microsoft.com
Your technical owner should know which credential each connection uses and how to replace or revoke it. That information belongs in controlled operational documentation.
Also distinguish access granted on behalf of a user from access held by an application independently. Those choices affect whose authority the agent exercises.
AI makes credential management another part of automation that the business needs to get right.
- Log What the Agent Does
If an agent changes a customer record at 2:14 Tuesday afternoon, can you reconstruct the transaction?
You should be able to identify the agent, initiating user or workflow, action, affected resource, result, and any required approval.
Microsoft recommends audit fields including agent identity, effective permission scope, action, resource, and identifiers that connect related events across systems. learn.microsoft.com
Those records can help explain the workflow. They should not be treated as a complete account of the model’s internal reasoning. An agent’s later explanation of its behavior is not a substitute for independent activity records.
Decide where logs live, who can access them, and how long they need to be retained. Protect them from alteration and unnecessary disclosure. Logging can itself create sensitive records if prompts, documents, or customer information are captured indiscriminately.
Verify that important actions actually produce usable records.
A useful AI system should not become an accountability blind spot.
- Monitor AI Agents Like Other Security-Relevant Identities
Logging records activity. Monitoring helps someone notice when that activity deserves attention.
Suppose an agent normally reads ten documents each morning and suddenly accesses thousands. Or an agent assigned to one workspace begins requesting information elsewhere. Perhaps it starts using a new tool, generating unusual exports, or repeatedly failing authentication.
Those events do not automatically mean the agent has become malicious. They may reflect a configuration mistake, compromised credential, manipulated workflow, changed integration, or unexpected behavior.
They still deserve investigation.
Define what normal activity looks like for the agent’s purpose. Then establish useful alert conditions and assign responsibility for responding.
Someone needs to know which alerts require immediate containment, which need investigation, and where to escalate when the technical owner is unavailable.
Monitoring also costs time. Before deploying an agent, account for the work of reviewing alerts and tuning noisy rules.
An alert nobody owns is another unattended task.
- Make Sure You Can Shut It Off
Every business deploying an agent with meaningful access should answer:
How do we stop this agent right now?
Not next week. Not after tracking down the developer. Not after discovering which API keys it uses.
Microsoft documents options for disabling individual agent identities or blueprints and using access policies to block broader agent authentication. Some controls require particular licensing and administrative permissions. learn.microsoft.com
But stopping new authentication is only part of containment. Microsoft’s guidance identifies persistent tokens, shared credentials, and downstream systems that do not recheck authorization as potential obstacles. learn.microsoft.com
Your shutdown procedure should cover the identity, active workflow, connected applications, credentials, and remaining access paths. Check whether already queued actions or other automations can continue.
The control should operate outside the agent’s own instructions and cooperation.
Test it in a controlled environment. Record what stopped, what continued, and how long containment took.
A kill switch you have never tested is an assumption.
- Include AI Agents in Incident Response
Imagine discovering that an agent sent confidential information to the wrong recipient.
Your incident response plan may explain what to do when an employee account is compromised. Does it identify what to do with the agent?
NIST’s incident response guidance places preparation, detection, response, and recovery within broader cybersecurity risk management. My recommendation is to apply that approach to agents that can affect company systems and information. csrc.nist.gov
Identify who can contain the agent, preserve activity records, investigate connected systems, revoke access, and coordinate recovery.
The response should establish which information the agent accessed, what it changed or sent, and whether exposed credentials need replacement. Appropriate business, legal, or compliance personnel should determine any notification obligations.
Define who can authorize a return to service and what must be corrected first.
Restarting an agent without understanding the failure may recreate the same problem.
- Govern the Entire Lifecycle
Agents change.
Someone revises the instructions, connects another data source, adds a tool, or finds another useful task. Permissions that made sense six months ago may no longer fit.
Review access when the workflow, tools, data, or deployment environment materially changes. Microsoft explicitly recommends these change-triggered reviews. learn.microsoft.com
Also establish a review schedule appropriate to the agent’s risk.
Ask whether the agent still needs to exist, whether its purpose has changed, whether its access remains necessary, and whether its business sponsor and technical owner are still current.
Test significant changes before production use. Preserve a record of what changed and who approved it.
When a pilot ends or an agent is retired, remove the integrations, credentials, and permissions that no longer serve an approved purpose. Preserve necessary records according to company requirements.
AI agents need onboarding, review, and offboarding too.
AI Governance Is Becoming Cybersecurity Governance
This is where the four articles in this series have been heading.
As businesses connect AI to tools and authorize workflows, they need to ask questions about its authority:
- What can it access?
- Under whose authority does it operate?
- Which actions require approval?
- Who monitors it?
- Can we reconstruct what it did?
- How quickly can we stop it?
These are familiar cybersecurity questions. We already ask them about employees, administrators, vendors, applications, and service accounts.
AI agents belong in that conversation.
Business leaders approve the purpose and acceptable authority. IT and security teams implement and maintain technical controls. Process owners decide which actions require review. Legal and compliance personnel advise on obligations when sensitive information or regulated activities are involved.
These responsibilities can be shared. They should never be undefined.
Your Next Insider Threat May Not Be Human
An AI agent is not literally an insider threat in the traditional human sense. The analogy is useful because it focuses attention on trusted access.
An agent can possess legitimate credentials, access sensitive information, interact with approved applications, and perform actions downstream systems accept.
It can still do something management never intended.
The cause might be a bad instruction, excessive permissions, compromised credentials, malicious input, misunderstood context, or behavior its designers did not anticipate.
After an incident, the company’s first question will be simpler:
What did it have access to, and why was it allowed to do that?
Build a deployment that can answer that question before something goes wrong.
The Goal Isn’t to Stop Using AI
Businesses should pursue useful AI applications. The value will depend on the task, the quality of the integration, and the work needed to operate it responsibly.
A workflow that saves employee time but creates unmanageable review work needs attention. So does an agent whose benefits depend on broad access nobody can explain.
Increased capability should come with increased control.
If an AI can read information, govern its access. If it can take actions, govern its authority. If it has an identity, manage its lifecycle. If it can affect important systems, monitor it. If something goes wrong, make sure you can stop it.
Start with one connected agent or workflow. Document its purpose, owners, access, permitted actions, approval rules, monitoring, and containment procedure.
Then verify that the deployed system matches the document.
Your AI does not have to become malicious to become a security problem. It needs access, capability, and insufficient controls.
As AI moves from answering questions to taking action, AI governance becomes part of cybersecurity governance.