Her advice is sensible. Agents need the same basics you already apply elsewhere: least privilege, identity management and monitoring. One piece of that advice needs a correction for Windows and Microsoft 365 shops. The Spiceworks piece says to make sure Microsoft 365's Unified Audit Log is enabled. For many smaller organizations, it isn't on by default.
Microsoft Defender: No threats detected
Scan details
Why agents differ from the chatbots you already manage
The National Institute of Standards and Technology (NIST) defines the category. Its Center for AI Standards and Innovation (CAISI) describes AI agent systems as able to plan and take autonomous actions that affect real-world systems. On January 12, 2026, CAISI opened a formal request for information on securing them. NIST said the request focused on risks that come from combining AI model outputs with the functions of ordinary software. It named three groups:
- Adversarial data, such as indirect prompt injection
- Insecure models, such as models affected by data poisoning
- Harmful actions with no attacker involved, such as specification gaming or pursuing misaligned objectives
Comments closed on March 9, 2026, under docket NIST-2025-0035, and NIST has since published a summary analysis of the responses.
Identity is the other new problem. Agents usually don't borrow a user's session. They tend to run under their own API keys, service accounts and OAuth tokens, which the industry calls non-human identities. OWASP published its Top 10 for Agentic Applications on December 9, 2025. Its third entry, ASI03, is Identity & Privilege Abuse, which covers cases where leaked credentials let agents act far beyond their intended scope. The list opens with ASI01, Agent Goal Hijack, and ASI02, Tool Misuse. Further down are agentic supply-chain flaws, memory poisoning and "rogue agents."
Readiness also lags. Cisco's State of AI Security 2026 report found that 83% of surveyed organizations planned to deploy agentic AI in business functions, while only 29% felt ready to do so securely. Those are survey answers about plans and confidence. They don't measure breaches.
Section summary: An agent behaves like a new employee who works at machine speed, has system access and rarely questions an odd instruction. The standards bodies agree this is a new kind of risk.
Three ways agents get compromised
1. Prompt injection
When an agent reads inbound content such as support tickets, customer email, vendor invoices or web pages, an attacker can hide instructions in that content. Phishing has to fool a person. Prompt injection targets software that follows instructions by design.
Spiceworks gives an example: an invoice-triage agent receives a poisoned document telling it to quietly forward sensitive data to an outside address. That is an illustrative scenario, not a reported case. De Fremery says no confirmed prompt-injection attacks on business-process agents like this have surfaced yet, although exploits against AI coding assistants and developer tools are well documented. OWASP's own examples include EchoLeak, where hidden prompts turned a copilot into an exfiltration channel.
2. Broad permissions become a skeleton key
Agents tend to get wide permissions so they don't break mid-task, and an attacker who compromises one gets all of them. Spiceworks cites researchers who showed that compromised Model Context Protocol (MCP) servers exposed private repositories. It also says Cisco's report describes a fake npm package, posing as an email integration, that copied outbound messages to an attacker while the agent stayed within its authorized permissions. That last detail matters: nothing looked out of bounds.
3. Shadow agents
Spiceworks cites UpGuard research, reported by Cybersecurity Dive, that more than 80% of employees use unapproved AI tools. It also cites a Dark Reading poll in which 48% of security professionals named agentic AI the top attack vector for 2026. We could not independently verify either figure, so treat both as reported claims with unconfirmed survey methods.
Cisco's own research on the open-source agent OpenClaw is better documented. Cisco's researchers ran a third-party skill called "What Would Elon Do?" against the agent. Their Skill Scanner reported nine findings, two critical and five high severity. The skill told the bot to run a silent curl command that sent data to a server controlled by the skill's author. It also used prompt injection to make the assistant skip its safety guidelines. Cisco noted that the skill had been artificially pushed to the #1 spot in its repository. Popularity is not a trust signal. Cisco also cites research finding that 26% of more than 31,000 analyzed agent skills had at least one vulnerability.
Section summary: The threats are injected instructions, inherited privileges and unvetted components. Each one can look like legitimate activity to traditional security tools.
The playbook: old principles, new identities
Spiceworks' central point holds up: you don't need a new governance committee to get started. Here is the practical version.
- Inventory first. Many core business apps now include agent features that may already be switched on. For each agent, record its owner, what data it can reach, which tools it calls, and what identity and credentials it uses.
- Treat each agent like a new hire's access request. Spiceworks says OWASP's guidance uses the term "least agency": give an agent only the autonomy a bounded task requires. Scope permissions tightly, use short-lived credentials instead of long-lived API keys where the platform supports it, and review access regularly, as you would for a contractor.
- Require human approval for high-stakes actions. Financial transactions, record changes, external communications and anything involving personal data should need a person's sign-off. One approval click costs far less than an agent emailing 10,000 customers the wrong price.
- Push vendors on specifics. Ask:
- What permissions do your agents request by default, and can we restrict them?
- How are agent actions logged, and can those logs go into our SIEM?
- What happens when an agent receives malicious input?
- Baseline behavior, not just the network. A compromised agent makes valid API calls during business hours, so login-anomaly rules won't catch it. If a support agent normally handles 50 tickets an hour and suddenly runs bulk database queries, investigate. Pay particular attention to where the agent sends data. Reading customer records for a report is normal. Writing them to an external endpoint is not.
None of these controls stops prompt injection outright. They limit how much damage a successful one can do.
The Microsoft 365 audit log gap
The Spiceworks advice to turn on the Unified Audit Log is right. Many admins still assume it is already running. Microsoft's documentation says audit logging is on by default for Microsoft 365 organizations, but it also says auditing isn't enabled by default for Small and Medium Business (SMB) licenses, including Microsoft 365 Business Basic, Business Standard, and Business Premium. In addition, unmanaged tenants that use free trials of enterprise licenses don't have auditing enabled by default. In both these cases, you must manually enable auditing for your organization.
Some third-party guides still say Business Premium has auditing on by default. Microsoft's current documentation is the authority, so check your tenant rather than trust either claim. One consultancy described the risk this way: "There is no error message and no warning. The gap only shows up on the day someone needs to search the log and finds there is nothing in it."
How to check and enable auditing
Prerequisite: You must be assigned the Audit Logs role in Exchange Online to turn auditing on or off. By default, the Compliance Management and Organization Management role groups on the Permissions page in the Exchange admin center have this role.
- Connect to Exchange Online PowerShell and run:
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
Truemeans auditing is on. Run this in Exchange Online PowerShell specifically. Microsoft warns that the same cmdlet in Security & Compliance PowerShell always returnsFalse, even when auditing is on. - If the result is
False, sign in to the Microsoft Purview portal and select the Audit solution card. If it isn't shown, select View all solutions, then Audit under Core. Then select the Start recording user and admin activity banner. - Alternatively, in Exchange Online PowerShell run:
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true - Wait. Microsoft says the change can take up to 60 minutes to apply, and events may take several hours to become searchable.
- Optionally, check who has changed the setting before with
Search-UnifiedAuditLog -Operations Set-AdminAuditLogConfig. The records include the admin, the time and the source IP address.
What success looks like: the check command returns True, the Purview banner is gone, and audit searches return results a few hours later.
Know what the log covers
According to Microsoft, Audit (Standard) keeps records for 180 days, and actual retention depends on retention policies and user licensing. Audit (Premium) features require an E5 or qualifying add-on license plus the Microsoft 365 Advanced Auditing service plan enabled for each user. If auditing is off, you also lose access to audit data through the Office 365 Management Activity API and Microsoft Sentinel. That matters if you planned to send agent activity to a SIEM.
One detail matters directly for agent security. Microsoft says auditing user interactions with non-Microsoft 365 AI data requires pay-as-you-go billing to be enabled. That covers Copilot in Microsoft Fabric, Microsoft Security Copilot, Microsoft Copilot Studio, and connected or cloud AI applications. If your agents are built in Copilot Studio, the base audit setting may not capture what you need.
Even with everything enabled, the Unified Audit Log records user and admin activity in Microsoft services. It will not necessarily capture every action a third-party agent takes through its own API or connected app. Use the agent platform's own logs alongside it. Spiceworks also notes that ServiceNow records system activity by default, and that Salesforce's detailed Event Monitoring requires the Shield add-on, while its basic Setup Audit Trail still shows administrative changes.
Section summary: Confirm in your own tenant that auditing is on, know what your license keeps and for how long, and don't assume one log covers every agent.
The bottom line
The case for urgency is mostly vendor surveys plus one well-documented malicious skill. Confirmed attacks on business-process agents have not yet appeared. Organizations that have also bought Cisco's or anyone else's AI security tooling should keep that in mind.
Still, the recommended steps cost little and most are things you should already be doing: list your agents, limit their permissions, require approval for consequential actions, question your vendors, and make sure the audit log you'll need during an incident is actually recording.