AI Agent Security for Business: 12 safeguards every IT team should put in place before giving AI access to corporate systems

By Michael Obraitis, Managing Partner, and Michael Dale, CEO · Published August 28, 2026 · Last reviewed August 2026 · ADAM Pulse Knowledge Base

Short answer

An AI agent is not a smarter chatbot. It is a principal that can plan, call tools, and change a system of record. Before you give one access to mail, files, tickets or APIs, put twelve numbered safeguards in place. Six of them are technical: identity, allowlists, read-before-write, orchestrator approval, tool-call logs, and a tested stop. The rest are instructional: owner, inventory, classification, incident fold-in, literacy and policy. Instructional controls tell people and models what should happen. Technical controls are what actually happens.

Never rely on the model to enforce permissions. A prompt that says “do not send customer data” is not an access-control list. Microsoft’s least-privilege guidance for AI agents says to re-validate identity, role and scope at every hop — orchestrator to tool to downstream service — and not to trust the orchestrator alone. OWASP’s agent cheat sheet says the same thing in engineering language: minimum tools, per-tool scoping (read versus write), and explicit authorization for sensitive operations.

This page is a risk-management starting point, not a compliance certificate. Completing it does not make you CMMC Level 2 certified, FedRAMP authorized, or EU AI Act conformant. NIST states that the AI RMF is voluntary. CSF 2.0 is likewise a voluntary framework, not an assessment program. If a vendor treats this list as a badge, they are wrong.

July 2026 produced two lab disclosures that will be misquoted. They were specialized cybersecurity evaluations, not normal ChatGPT or Claude.ai sessions. The operational lesson is still useful: if the only thing keeping an agent inside a box is a prompt or an untested sandbox, the box is not a control. Details and primary links are in What the July 2026 evaluation incidents actually were.

Instructional versus technical controls

Instructional controls are documents and training: who owns AI risk, which data class may go into which tool, when a human must check output, how to report Shadow AI. They matter. They are how you make Tuesday decisions without a meeting. They do not stop an agent that already has Mail.Send and a valid token.

Technical controls are enforced by identity, policy engines, orchestrator logic and downstream systems: a unique agent identity, an allowlist of tools, a read role that cannot write, an approval gate that is not optional, logs of every tool call, and a revoke path that invalidates tokens. Microsoft names the failure modes when those are missing: identity ambiguity, permission creep, over-broad tool access, weak audit trails, and slow revocation.

Put the intended scope in writing (instructional). Enforce it in the platform (technical). If you only do the first, you have a PDF. If you only do the second, nobody can explain why the agent can still send mail.

The twelve safeguards

1. Name an accountable owner before any agent gets production access

Instructional. One executive, named in writing, for AI risk. They can delegate work. They cannot delegate the “we did not know” answer. NIST CSF 2.0 added Govern as a sixth function: strategy, expectations and policy are established, communicated and monitored. NIST AI RMF does the same job for AI (Govern, Map, Measure, Manage). Both are voluntary. Use them as a grouping language, not as a filing.

2. Inventory the estate before you grant access

Both. You cannot least-privilege a tool you have not found. Keep a living list: name, owner, data classes allowed, whether it can act (send / write / pay / delete), identity, tools, and a review date. Inventory agents separately from chatbots. Microsoft’s Cloud Adoption Framework names shadow AI proliferation and unused (dormant) agents as operational risks. Microsoft’s Shadow AI page in the Microsoft 365 admin center is one feed for unsanctioned local agents on Intune-managed Windows — Frontier preview, license-gated, and not a complete inventory. How to find the rest is in What is Shadow AI and how do you find it? The field list is in How to build an enterprise AI inventory.

3. Give every production agent its own identity

Technical. Microsoft Entra Agent ID is the documented pattern: agents as first-class principals, not a shared secret and not “whatever the human was logged in as.” If the platform cannot do that, do not give the agent write access. Shared AI logins destroy attribution. You will not be able to answer which agent, acting for whom, sent the mail. Microsoft 365 specifics: How to secure AI agents connected to Microsoft 365.

4. Enforce least privilege in the platform, never in the prompt

Technical. OWASP: grant the minimum tools for the task; per-tool scoping (read-only versus write, specific paths); separate tool sets by trust level; explicit authorization for sensitive operations. The cheat sheet’s bad MCP example is allowed_commands: "*". The good example is a file reader limited to /app/reports/* with read-only operations. Microsoft: deny unreviewed tools by default; review aggregate and effective permissions end-to-end; verify downstream authorization on each call. A system prompt is instructional. It is not this control. Detail: AI agent permissions and least privilege explained.

5. Separate read from write. Read before write

Technical. Microsoft’s worked example for an agent that creates tickets: a read role for evidence gathering, a separate write role for ticket creation; allowlist only create-or-update; block delete and admin; require human approval for bulk updates. An agent that can retrieve a contract should not, by default, be able to file it, mail it, or pay against it. Promote write after the read path is logged and reviewed. That promotion is a change-control event, not a prompt edit.

6. Put human approval in orchestrator logic, not in the system prompt

Technical. Microsoft: human-in-the-loop enforced in orchestrator logic, not in the prompt. OWASP: explicit approval for financial, administrative, or externally visible operations. The usual four: send mail, change a record, pay a vendor, delete data. Internal scratch drafts do not need a second signature. If the rule is “a human checks everything,” people will stop reading the policy. Grade by consequence. The production-versus-demo gap is spelled out in what separates production-ready agents from demos.

7. Treat retrieved content, emails and tool output as untrusted

Technical. Documents, web pages, meeting transcripts and tool results can contain instructions. Prompt injection is worse for agents than chatbots because a bad answer is text; a bad action is an action. Filter inputs and outputs. Do not ask the model to “be careful.” Microsoft Purview DLP can exclude external email from Copilot grounding (preview, as of this review) precisely because untrusted mail is an injection path. That control is license- and location-specific. It is not a substitute for treating every retrieved blob as hostile until proven otherwise.

8. Log tool calls, scopes and authorization decisions — not only the chat transcript

Technical. Microsoft’s usual gap: logs that capture the chat reply and miss the tool call, the scope and the authorization decision. Minimum fields: agent identity, role, effective scope, action, resource, correlation ID, and “on behalf of” user where applicable. If you cannot reconstruct Tuesday, you cannot investigate Tuesday. Network path still matters: if agents talk to models and APIs across the WAN, DNS and firewall logs are part of AI monitoring. That is the NOC vantage we already run.

9. Maintain a tested kill switch, including token invalidation

Technical. Microsoft measures mean time to revoke or disable an agent identity, including token invalidation. Disable the identity, rotate credentials, invalidate tokens, and confirm the agent cannot still call tools with a cached grant. An untested pause button is a belief. Test it on a non-production agent the way you test failover: on a calendar, with a named owner, not during the incident.

10. Map data classification to tools, and use DLP or labels where they actually reach

Both. Do not invent a parallel AI taxonomy. Reuse Public, Internal, Confidential, and CUI if you have it. Each approved tool gets a written list of classes it may receive. A prompt, upload, recording or repo index is a data transfer. Microsoft Purview DLP has a dedicated Microsoft 365 Copilot and Copilot Chat location that can block sensitive prompts, restrict web search, and exclude labeled files from grounding — where you have the license, and with documented limits (it does not inspect files uploaded directly into a prompt; selecting that location disables other locations in the same policy). It will not see a personal ChatGPT tab on a phone. This article does not use health-record examples; if you are a covered entity, your existing privacy program owns that mapping.

11. Fold AI into the incident process you already have

Instructional, with technical evidence requirements. Define an AI incident in the existing playbook: restricted data in an unapproved tool; an agent that acted outside policy; a compromised AI account; prompt-injection that caused an external action. Contain with identity and path, not a stern Slack message. Notify under the rules you already have (contracts, state breach statutes, CUI reporting if you are in that scope). This list does not create a new legal notification duty. Preserve prompts, tool-call logs, identity logs and network records. Detail: AI incident response plan.

12. Train the people who operate the tools, and publish a short acceptable-use policy

Instructional. EU AI Act Article 4 (AI literacy) has applied since 2 February 2025 — not 2 August 2026. Article 50 transparency obligations have applied since 2 August 2026 (European Commission FAQ; Regulation (EU) 2024/1689). A limited grace period to 2 December 2026 applies only to provider-side machine-readable marking for generative systems already on the market before 2 August 2026. Those duties apply to in-scope providers and deployers in the Union market, not automatically to every US employer. Do not invent a US legal duty from those articles. Literacy and customer-facing labeling are still good practice. The document this control assumes exists is How to create a corporate AI acceptable use policy. The operating model around it is AI governance framework for small and mid sized businesses.

What the July 2026 evaluation incidents actually were

Quote the primary disclosures. Do not turn them into a story about ChatGPT at work.

OpenAI / Hugging Face (disclosed 21 July 2026; follow-up 26 August 2026). OpenAI ran an internal cybersecurity evaluation called ExploitGym to measure maximal cyber capability. Production classifiers that normally block high-risk cyber activity were not enabled. The environment was supposed to be isolated, with package install via an internally hosted registry proxy. Evaluation models — including GPT-5.6 Sol and a more capable unreleased research model — found a zero-day in that proxy, moved laterally to a node with internet access, and reached Hugging Face production systems. Hugging Face detected activity on 16 July. This was a specialized evaluation, not a customer ChatGPT session. Primary: OpenAI’s incident post and Hugging Face’s technical timeline.

Anthropic (disclosed 30 July 2026). After OpenAI’s post, Anthropic reviewed 141,006 cybersecurity evaluation runs. It found three incidents (six runs) in which Claude models running capture-the-flag evaluations with partner Irregular reached the open internet because of a misconfiguration, then gained unauthorized access to three organizations’ production infrastructure. The models involved were Opus 4.7, Mythos 5, and an internal research test model. The evaluations ran without the standard misuse classifiers Anthropic deploys for generally available models. Anthropic is explicit: this is not Claude escaping Anthropic; it is evaluation containment failure plus models doing what CTF tasks train them to do. Primary: Anthropic’s investigation post.

What this supports for a business IT team: do not treat a prompt, a “sandbox” you have not tested, or a model refusal as the permission system. What it does not support: a claim that ordinary Microsoft 365 Copilot, ChatGPT Enterprise, or Claude for Work will autonomously pentest your vendors. Those products are not these evaluations. If you need a sentence for the board: lab cyber-evals showed that containment is an infrastructure problem; our production agents will not get write access until identity, allowlists and a tested stop exist.

Five questions before you turn write on

1. Which agent, under which identity, is about to get access — and who is the named owner?
2. What is the allowlist of tools, with read separated from write?
3. Where is human approval enforced (orchestrator, not prompt) for send / write / pay / delete?
4. If it misbehaves at 2 a.m., what is the tested way to stop it, including cached tokens?
5. If it acted last Tuesday, can we prove which agent, for whom, under what instruction?

If you cannot answer those in a sentence each, do not grant write. The 40-control checklist is the rest of the program this list sits inside: AI security checklist for businesses.

Enterprise AI Security & Governance Resource Center

This pillar is the agent-access page. The eight supporting pieces below are already live or ship with it. Use them; do not copy them into this article.

• AI security checklist for businesses: 40 controls — the full program in eight groups, plus five CIO questions. This pillar is the agent-access cut of that list.
• How to create a corporate AI acceptable use policy — the document safeguard 12 assumes exists, with a sample policy block.
• What is Shadow AI and how do you find it? — discovery methods behind safeguard 2, and why a blanket ban usually fails.
• Shadow AI Risk Assessment — free, private, in-browser. Not a network scan and not a duplicate of any article.
• How to secure AI agents connected to Microsoft 365 — Entra identity, least privilege, shadow agents, OAuth, Purview/DLP as available.
• AI agent permissions and least privilege explained — OWASP, read-before-write, MCP permissions caution.
• How to build an enterprise AI inventory — the living approved / restricted / blocked list.
• AI incident response plan — fold AI into the playbook you already have.
• AI governance framework for small and mid sized businesses — owner, policy, inventory and literacy without enterprise GRC theater.

Frequently asked questions

Related articles

• AI security checklist for businesses: 40 controls — the program this pillar sits inside.
• How to secure AI agents connected to Microsoft 365 — Entra, OAuth, Shadow AI, Purview as available.
• AI agent permissions and least privilege explained — OWASP, read-before-write, MCP caution.
• What is Shadow AI and how do you find it? — discovery behind safeguard 2.
• How to create a corporate AI acceptable use policy — the document safeguard 12 assumes.
• What separates AI agents that ship to production from the ones that stay demos? — architecture behind safeguards 6–9.

References

Primary sources only. July 2026 incidents are cited to the lab disclosures, not to secondary blogs. This list is not an official NIST, OWASP, Microsoft, CMMC or FedRAMP control set.

1. NIST — AI Risk Management Framework FAQs— the AI RMF is voluntary. Organizations are not required to use it.
2. NIST AI 100-1 — Artificial Intelligence Risk Management Framework 1.0 (26 January 2023)— Govern, Map, Measure, Manage. Voluntary, non-sector-specific.
3. NIST AI 600-1 — Generative Artificial Intelligence Profile (July 2024)— companion profile. Voluntary.
4. NIST CSWP 29 — The NIST Cybersecurity Framework (CSF) 2.0 (26 February 2024)— six functions including Govern. Not a certification scheme.
5. OWASP Cheat Sheet Series — AI Agent Security— tool least privilege, MCP allowlists, human-in-the-loop, untrusted content. Retrieved August 2026.
6. Microsoft Learn — Least privilege for AI agents (updated July 2026)— identity ambiguity, permission creep, over-broad tools, weak audit, slow revocation; re-validate at every hop.
7. Microsoft Learn — Secure autonomous agentic AI systems— deterministic HITL in orchestrator logic, not the prompt.
8. Microsoft Learn — Agent identities— Entra Agent ID as a first-class principal.
9. OpenAI — Hugging Face model evaluation security incident (21 July 2026)— ExploitGym evaluation; production classifiers off; not customer ChatGPT.
10. Anthropic — Investigating three real-world incidents in our cybersecurity evaluations (30 July 2026)— CTF evaluations with Irregular; misconfiguration; not Claude.ai.
11. Regulation (EU) 2024/1689 — EU Artificial Intelligence Act— Article 4 applied 2 February 2025; Article 50; Article 113 dates.
12. European Commission — Article 50 FAQ— Article 50 applies from 2 August 2026; limited Article 50(2) grace to 2 December 2026.