Kief Studio

AI Agent Monitoring: Why Your Security Tools Can't See Your Agents

Protect

  • Published
  • Updated
  • 12 min read
A security monitoring dashboard on a monitor in a dark office, rows of activity where AI agent events blend with people's

TL;DR: Your security monitoring probably records what your AI agents do. It just cannot tell those actions apart from a person's, because agents often sign in with a person's account or a shared key and use the same tools your staff use. Good AI agent monitoring starts with giving each agent its own identity, logging its tool calls, and alerting on a short list of risky actions.

AI agent monitoring is a question most small businesses have not asked yet, and it is a fair one. If an agent books appointments, answers email or updates invoices for you, what does your monitoring actually show when it does that work?

Usually the answer is a normal day: a login that worked, ordinary requests, an email from a real mailbox. That gap in AI agent monitoring is worth fixing, and it is fixable with tools you probably already pay for.

What do SIEM and EDR actually do?

SIEM stands for security information and event management. NIST defines a SIEM tool as an "application that provides the ability to gather security data from information system components and present that data as actionable information via a single interface." (NIST glossary, from SP 800-128) In practice it pulls logs from your email, firewall, cloud apps and servers into one place you can search and get alerts from.

EDR stands for endpoint detection and response. It is software that watches what happens on each device: programs starting, files changing, connections going out. An endpoint, in CISA's words, covers "laptops, desktops, workstations, smartphones, servers, IoT devices, virtual machines, and other computing devices." (CISA Eviction Strategies Tool)

A ten-person office may not own anything with either label. The activity log in your email admin console and the sign-in history in your accounting system are the same ideas in smaller pieces, and everything below about AI agent monitoring applies to them.

Why does an AI agent's activity look like an ordinary user?

Because, to your systems, it is one. Four things make agent activity blend in.

Two workstations at night, one with a person seen from behind and one empty with an active screen, as AI agent activity
Without AI agent monitoring, an agent signed in with a person's login looks like a busy employee to your systems.

It signs in as somebody

The fastest way to set up an agent is often to hand it your login or an API key with broad access. NIST's identity team wrote in August 2026 that giving agents local account access "allows the agent to both impersonate the user and act with broadly scoped access," and that agents running commands with user authorization "undermines non-repudiation." (NIST, August 27, 2026) In plain words: the log says you did it, and nobody can prove you did not.

It uses tools you already trust

Security teams have long known that a valid login draws less attention than malware. MITRE's catalog of attacker techniques notes that adversaries "may choose not to use malware or tools in conjunction with the legitimate access those credentials provide to make it harder to detect their presence." (MITRE ATT&CK, Valid Accounts) An agent does the same thing for innocent reasons. It uses your real mailbox, your real CRM and your real payment tool, so there is nothing foreign for a scanner to flag.

It is busy, and busy looks normal

Agents can work fast, at all hours, in volume. CISA and its partners already warned about this with ordinary automation: "Automated systems such as ongoing management functions using service accounts and vulnerability scanners frequently perform highly privileged, possibly suspicious actions that drown analysts in log events if not appropriately categorized." (CISA, NSA, FBI and partners, February 2024) The same guidance warns that default logging often cannot "differentiate malicious activity from legitimate IT administrative activity." For AI agent monitoring, that means one more busy, privileged actor in the pile.

It often runs somewhere EDR cannot see

EDR watches devices. Many agents run in a cloud service and act by calling other services over the internet. When an agent reads a customer record or sends an email that way, there may be no program starting on any laptop you own. The evidence lives in the logs of the services it touched, which is exactly where AI agent monitoring has to look, through a SIEM or a careful person with admin access.

Here is the real risk. If someone tricks an agent, it does not install anything. It uses the permissions you gave it. The UK's National Cyber Security Centre wrote that "it's very possible that prompt injection attacks may never be totally mitigated in the way that SQL injection attacks can be." (NCSC, December 8, 2025) Prompt injection means hiding instructions in content the agent reads, such as an email or a web page. If you cannot fully prevent it, AI agent monitoring is how you see it.

How big is the AI agent monitoring gap right now?

The numbers are recent. IBM's 2026 Cost of a Data Breach study, run with the Ponemon Institute across 602 breached organizations, found:

  • Less than half of organizations studied (46%) report securing non-human identities in their AI workflows. Non-human identities are the service accounts, API keys and machine credentials agents use.
  • Security incidents involving shadow AI, meaning staff using AI tools the business never approved, more than doubled, to 43% from 20% the year before.
  • The average breach took 247 days to identify and contain.

(IBM, Cost of a Data Breach Report 2026)

Government guidance names the same gap. In May 2026, CISA, the NSA and the cyber agencies of Australia, Canada, New Zealand and the United Kingdom published joint guidance on agentic AI. Its short list of risks includes "expanded attack surface, privilege creep, behavioral misalignment, obscure event records." (CISA, May 1, 2026) In plain words: records that do not make clear what an agent did or why, which is the AI agent monitoring gap.

Place those side by side. More than half of organizations have not secured the identities their agents use, and it already takes most of a year to find and contain a breach. An agent acting under a borrowed login, with no AI agent monitoring, does not make that clock any faster.

What should AI agent monitoring record?

OWASP's logging guidance for software already splits "who" into "human or machine user." (OWASP Logging Cheat Sheet) For AI agent monitoring, record this for every action that changes something:

Macro view of server drive bays with activity lights, where activity logs for AI agents are stored and reviewed
AI agent monitoring logs every action that changes something under the agent's own identity, not a person's.
  1. The agent's own identity. A name like agent-invoices, not a person's email address.
  2. Who it acted for. The person or job that started the run. The OAuth token exchange standard has an "act" claim for exactly this, to "express that delegation has occurred." (IETF RFC 8693)
  3. The tool and the action. "CRM: update record," "email: send," "payments: refund."
  4. The target. Which record, which recipient, which amount.
  5. What it read before it acted. The email or page that fed the decision, where a planted instruction would show up.
  6. The result, including failures. NCSC recommends logging "full input and output of the LLM, as well as tool use, API calls etc.," and notes that "detecting and responding to failed tool calls or API calls could identify earlier stages of an attack."
  7. Any approval. Who said yes to a gated action, and when.
  8. When, to the second, with a consistent time zone across systems so events line up.

Then send those records somewhere the agent cannot edit. CISA's guidance recommends aggregating logs "in an out-of-band, centralized location that is write-once, read-many to avoid the risk of attackers modifying or erasing logs." If you want the hands-on mechanics, the log analysis and management guide (opens in a new tab) on HxHippy, my off-clock site, walks through them.

How can you tell an agent's actions from a person's?

NIST's National Cybersecurity Center of Excellence put the goal plainly in its February 2026 concept paper: identify agents "such that access management systems can distinguish between agent and human identities," and "link specific AI agent and software systems actions to the identity of the non-human entity." (NIST NCCoE, February 2026)

In a small business, AI agent monitoring that meets that goal looks like this:

  • One account per agent. Never a shared bot account, never a person's login.
  • A naming rule you can filter on. Every agent account starts with the same prefix, so one search shows all agent activity.
  • A named key per agent. If a service only supports API keys, create one per agent and label it, so the key name appears in the log.
  • A named owner. A person on payroll who answers for that agent.
  • The ten-minute test. Pick one thing an agent did yesterday. If you cannot find it in your logs, with the agent's name on it, in under ten minutes, your AI agent monitoring cannot see it yet.

Amelia, my wife and Kief Studio's co-founder and CEO, has already written the full definition of what a non-human identity for an AI agent is (opens in a new tab), so I will not repeat it here.

What does least privilege look like for an agent identity?

Least privilege means the agent gets only the access its one job needs. AI agent monitoring and least privilege work as a pair: logs without narrow access just give you a clearer view of an agent that can reach too much.

A dark office corridor where only one door is open and lit, showing least privilege access for an AI agent identity
Least privilege makes AI agent monitoring simpler: the agent gets the one door its job needs and the rest stay closed.

NIST's August post warns that "bearer tokens and static API keys do not prove identity" and that "API keys provide broad, unscoped access." Federal News Network reported that Ryan Galluzzo of NIST applies least privilege to agents: an agent should not automatically inherit everything its human sponsor can access. (Federal News Network, October 14, 2026) OWASP's Top 10 for agentic applications lists Identity and Privilege Abuse among the highlighted threats. (OWASP, December 2025)

For AI agent monitoring, the practical test is simple. The invoice agent can read invoices and draft payments; if your logs ever show it changing user permissions, that alert should fire before anyone asks why. Give every agent an off switch that does not require disabling a person's account.

Checking each permission is only half the job. A run can stay inside every individual permission and still do something you never meant, which is why Amelia's piece on governing the sequence, not each click (opens in a new tab) is worth reading next.

Which agent actions should trigger an alert?

Good AI agent monitoring does not alert on everything, or nobody would read the alerts. CISA's advice is to "baseline account behavior" and alert on what departs from it. For agents, start with a short list:

  • Any payment, refund or change to bank details.
  • Any delete of more than a handful of records in one run.
  • Any export or download of a full customer list.
  • Any change to permissions, users, passwords or email forwarding rules.
  • A first message to an outside address the agent has never written to.
  • A burst of failed tool calls, which NCSC flags as an early sign of an attack.
  • Activity outside the agent's normal schedule or far above its normal volume.

Every alert in your AI agent monitoring needs a written next step: who gets it, what they check, and how they pause the agent. Our incident response guide covers what happens after the alert fires.

What does this mean for a business in Worcester or Central Massachusetts?

Few small businesses have a security analyst on staff, so AI agent monitoring has to be simple enough for the owner or office manager to check.

Massachusetts already sets expectations that fit this problem. The state's data security regulation, 201 CMR 17.00, asks businesses that store personal information of Massachusetts residents to include, to the extent technically feasible, "control of user IDs and other identifiers," access limited "to those who need such information to perform their job duties," unique identifications "to each person with computer access," and "reasonable monitoring of systems, for unauthorized use of or access to personal information." (201 CMR 17.04)

The regulation was written before AI agents and talks about people. My read is that an agent touching customer records belongs under the same controls: its own ID, narrow access and monitoring that can see it. Your attorney decides what the rule requires of you. A Shrewsbury dental office with an agent that confirms appointments, or a Worcester contractor with one that chases unpaid invoices, could meet the spirit of it with the steps below.

What AI agent monitoring can you set up this week?

  1. Monday: list every agent and automation that can change data, send mail or move money. Include the AI features inside tools you already use. Note which ones use a person's login.
  2. Tuesday: give the riskiest one its own account or its own labeled key, with an owner.
  3. Wednesday: turn on the audit logs in the systems that agent touches, and check that the agent's name shows up.
  4. Thursday: set three alerts from the list above, starting with payments, permission changes and bulk exports.
  5. Friday: run the ten-minute test. Then repeat the week for the next agent.

Frequently asked questions

Why does my security monitoring miss AI agents?

It usually records their actions but cannot tell them from a person's. Agents often sign in with a person's account or a shared key and use approved tools, so they look like a busy employee.

Is EDR alone enough for AI agent monitoring?

Not reliably. EDR watches devices. Many agents run in cloud services and act through other services, so the evidence sits in those services' logs rather than on any laptop you own.

Do I need to buy a SIEM for AI agent monitoring?

Not first. Start with a separate identity per agent, audit logs in the systems it touches, and a few alerts. A SIEM cannot label agent activity that was never labeled.

What should I log for every AI agent?

The agent's own identity, who it acted for, the tool and action, the target, what it read before acting, the result including failures, any approval, and an accurate timestamp, stored where the agent cannot edit it.

How do I tell an AI agent's actions from an employee's in the logs?

Give each agent its own account or labeled key with a consistent naming prefix, and record who it acted for. Then test it: find one agent action from yesterday in under ten minutes.

Does Massachusetts law cover AI agents?

201 CMR 17.00 predates agents and speaks about people, but it asks for controlled user IDs, need-to-know access and reasonable monitoring. Applying that to agents is a sensible reading; your attorney can confirm it.

This article is general information, not legal advice. Kief Studio is not a law firm, and reading it does not create an attorney-client relationship. Laws and regulations change, so check the current text and talk with a licensed Massachusetts attorney about your situation.

Where we fit

Logs nobody reads are not detection. Our threat detection and response work starts by taking inventory of what you run and deciding which signals matter, then collects and correlates those signals so one attack shows up as one alert, and writes the response path for each alert: who acts, what they check, what they do. The one-week plan above is where that inventory starts.

For systems we build and host, managed security monitoring is part of managed hosting on LTFI: we monitor, patch and harden what we host, and report what changed in plain language. You can see how LTFI watches what we host (opens in a new tab). Many clients keep their IT provider for laptops and help desk, and we work alongside them. 3am is a retainer, not a default, so after-hours response is written into the agreement or not promised.

Kief Studio is in Shrewsbury, and we work with businesses in Shrewsbury, Worcester and across Worcester County. Security is a byproduct of good engineering.

First conversation is free. No commitment.

Tell us what your agents touch