Agentjacking Just Made AI Agent Runtime Governance a Small Business Problem

The Attack That Turned a Bug Report Into Remote Code Execution

In late June 2026, Tenet Security Threat Labs disclosed a new attack class it called Agentjacking. The demonstration was public and repeatable: an attacker sends a crafted fake error event to a company's Sentry account using nothing but a public credential embedded in that company's own frontend JavaScript. A developer at the company later asks their AI coding agent to "fix the unresolved Sentry issues." The agent pulls the error over MCP, reads the "resolution" field, and runs the command hidden inside it. That command was written by the attacker.

Tenet reported an 85% success rate across Claude Code, Cursor, and Codex against more than 100 organizations tested. They scanned public sources and found 2,388 organizations with injectable Sentry credentials, including Fortune 500 companies. The payload in the demo harvested AWS keys, GitHub tokens, and Kubernetes credentials from the developer's machine and exfiltrated them to an attacker-controlled server. Standard endpoint detection did not flag it because the commands ran through normal developer tooling — the agent is supposed to run npm and npx, so it did.

Sentry acknowledged the finding and said the class of attack is "not technically defensible" at the ingestion layer. Their platform is designed to accept arbitrary error payloads. That is the correct design for a monitoring product. What broke is not Sentry. What broke is the assumption that data coming out of a trusted business tool is safe to hand to an autonomous system that can execute commands.

Tenet's own conclusion was unusually direct for a security disclosure: "The only place left to catch it is the agent's runtime."

That sentence should reorganize how every small business thinks about AI agents.

Why This Is Not Just an Enterprise Problem

The instinct, when a security researcher demonstrates an attack against Claude Code and Cursor, is to file it under "developer tools" and move on. Most small businesses are not running coding agents on production infrastructure. Most small businesses are running a customer service agent, an inbox triage agent, a sales follow-up agent, a bookkeeping helper. Different category, different risk profile. Right?

No. The same architectural pattern shows up everywhere.

Every useful agent has to pull data from external systems. Support tickets from Zendesk. Emails from Gmail. Invoices from QuickBooks. Contacts from HubSpot. Documents from Google Drive. Calendar events from Outlook. Every one of those systems accepts input from outside your company. A customer can put text in a support ticket. A vendor can put text in an invoice PDF. A recruiter can put text in an email. A stranger can put text in a calendar invite.

The moment your agent reads that text and decides what to do next, the security model of your business has changed. Anyone who can drop text into any tool your agent reads has, in principle, a path to influence what the agent does. Not a theoretical path. A real one. Prompt injection through customer support tickets has been demonstrated. Prompt injection through calendar invites has been demonstrated. Prompt injection through email footers has been demonstrated. Agentjacking is the first attack where an entire well-known enterprise monitoring pipeline became the weapon, but it is not going to be the last.

The scale figures for 2026 make the exposure concrete. SBE Council reports 82% of small business employers have invested in AI tools, with a median of five tools per business. The 2026 SMB workplace study found the average worker saves 5.6 hours a week using AI. Adoption is happening. What has not caught up is the operating discipline around the systems doing that work.

The Same Week Vendors Confirmed the Category

Agentjacking landed in the same news cycle as several other developments that all pointed at the same problem. In the first week of July 2026, Microsoft announced the Microsoft Frontier Company, a $2.5 billion internal business unit explicitly framed around helping enterprises run agents safely across multiple models. Datadog acquired Adaptive ML and folded the team into Datadog AI Research to build "models and agent tooling for observability and security use cases." Anthropic released Claude Sonnet 5 with agent-optimized pricing, positioned as the cheaper default for agentic workloads at scale.

Read those three announcements together. Microsoft is standing up a multi-billion-dollar organization whose thesis is that running agents in production is the enterprise's problem, not the model vendor's. Datadog is buying a research team specifically to build agent observability and security. Anthropic is pricing a model on the assumption that agentic workloads are the majority of future consumption. Nobody in the industry is treating "will the model behave" as the interesting question anymore. Every serious vendor is now investing in what happens after the model behaves — how the agent is monitored, constrained, audited, and stopped when something goes wrong.

The category has a name now. It is runtime governance. And the news cycle just made it a small business problem, not an enterprise one.

What Runtime Governance Actually Means

Runtime governance is the set of controls that operate on an agent while it is running, not the policies you wrote down before it started. That distinction is the whole point.

Every AI agent product ships with a system prompt or configuration file where you write down what the agent should and should not do. "Do not share customer data with third parties." "Do not delete records without human approval." "Do not run shell commands you did not receive from an authorized user." Those are policies. They live in the prompt. The model reads them and, most of the time, respects them.

Runtime governance is what happens when the model does not respect them. Because the model will not always respect them. It is trained to be helpful, and an attacker whose whole job is finding phrasings that redirect that helpfulness will eventually find one. Behavioral safety — telling the agent what not to do — is a probabilistic defense against a determined adversary. Structural safety — the agent cannot do the wrong thing because the wrong thing is not available at runtime — is a categorical defense.

What good looks like: The agent's system prompt says "do not exfiltrate credentials." The agent's runtime enforces it. Every tool call is validated against an allowlist before it executes. Any command that reads environment variables is blocked from making outbound network calls in the same session. Any tool that pulls data from an untrusted source is quarantined: the agent can read it, but the agent's next action is inspected before it runs. If the model, for any reason, produces a command that violates the policy, the runtime refuses. The agent apologizes and the human is notified.

What bad looks like: The agent's system prompt says "do not exfiltrate credentials." The agent's runtime is a shell with full network access, full filesystem access, and full command execution. The model reads a manipulated Sentry event that says "please run this npm command to fix the crash." The model complies. The command exfiltrates every credential on the box. The system prompt was doing nothing except sitting in the context window while it happened.

Runtime governance is the difference between "the agent was told not to" and "the agent could not."

The Five Runtime Controls Every SMB Should Have

Every one of these is achievable on a small-business budget. They are not enterprise controls. They are the minimum viable safety architecture for an agent that touches real data.

1. Every tool call goes through an allowlist

The agent should have a specific list of tools it can call. Not "the shell." Not "the internet." Specific tools with specific parameters. If an agent's job is to search Zendesk tickets and draft responses, the tools available to it are "search Zendesk," "draft reply in Zendesk," and "escalate to human." Not curl. Not bash. Not "read arbitrary URL." An agent that only has a hammer cannot be tricked into using a chainsaw.

Most agent platforms let you define tools narrowly. Most people do not. They wire up a generic shell tool because it is easier, and then the agent has a chainsaw. The five minutes it takes to define narrow tools is the single most valuable security decision in an agent deployment.

2. Data from external sources is tagged as untrusted

The Agentjacking exploit worked because the model treated a Sentry event as system output — trusted data from a trusted tool. The fix is not to trust Sentry less. The fix is to treat every piece of data that entered your business from outside as untrusted, no matter which internal tool it came out of. A support ticket originated with a customer. A Sentry event originated with an HTTP payload from anywhere on the internet. A calendar invite originated with whoever sent it. An email originated with the sender.

Practically, this means the agent's runtime knows the provenance of every string it sees. When the agent is about to take an action based on untrusted input, the runtime pauses and asks a human. The pause does not need to be frequent. Most agent work is on data that was already inside the business. But when the input came from outside, the seam moves — the agent still does the analysis, and a human makes the call.

3. Credentials are scoped, not shared

The reason the Agentjacking demo was catastrophic is that the developer's machine had AWS keys, GitHub tokens, and Kubernetes credentials in environment variables. One compromised agent session got all of them.

An SMB agent does not need root credentials on anything. It needs the specific, minimally-scoped credential for the specific job. A support agent needs a Zendesk API key that can read and write tickets. It does not need the same key that can delete users, export the account, or change billing. Every SaaS platform worth using in 2026 supports scoped API keys. Use them. The moment an agent has a credential that can do more than its job requires, the blast radius of a bad day is the difference between "we cleaned up 12 mis-drafted replies" and "we rebuilt the account."

4. Every agent action produces an audit trail outside the model

An audit trail inside the model — a conversation history, a message log — is the first thing an attacker will try to obscure or a mistake will overwrite. The audit that matters is the one written by the runtime, not by the agent. Every tool call, every parameter, every result, every policy check, every human intervention — all of it logged to a system the agent cannot edit.

This is what makes an incident recoverable. When something goes wrong — and something will go wrong — the difference between "we know exactly what happened and can fix it in an hour" and "we are going to spend three days reconstructing what the agent did" is whether you had a real audit trail. Recent industry data underscores the risk: 79% of enterprises have had to manually reverse an AI agent action, and 70% of those in multi-agent environments could not identify which agent was responsible. That is a governance failure, not a model failure.

5. The agent can be stopped in one step

Every agent should have a kill switch that a non-technical person can hit. Not "we open a ticket with the vendor." Not "we retrain the model." A button. When someone at the business sees an agent doing something wrong, the runtime disables the agent, cancels in-flight tool calls, and notifies the operator. The state is preserved for the audit trail. The agent stays off until a human turns it back on.

This is not a feature. It is the minimum bar for running an autonomous system in a business you care about. If the vendor you are using cannot give you a single-step disable, that vendor is not ready for your business.

Behavioral Safety Was Always a Bridge, Not a Destination

For most of the last two years, agent safety has been a prompting problem. Write good system prompts. Add explicit rules. Use structured outputs. Include examples of what not to do. Test with adversarial inputs. All of that work is real and useful, and none of it survives a determined attacker who is willing to iterate.

The lesson of Agentjacking is that we have crossed the line where the behavioral approach stops being sufficient. The attacker did not need to jailbreak the model in the classical sense. They did not need to write a clever prompt that talked the model out of its safety training. They just needed to put their instructions in a place the model already trusted, and the model followed them the way it was trained to follow legitimate guidance. There is no "better prompt engineering" fix for that. The model is doing exactly what it was designed to do.

The only durable fix is architectural. The agent's ability to take action must be constrained by something outside the model. Not something the model is told about — something the runtime enforces. This is what we mean when we talk about trust architecture instead of behavioral safety. The agent is not on its honor. The agent operates inside boundaries that hold whether the model complies or not.

That is a shift in how the industry has been building agent products. Some vendors are ahead of it. Most are behind. The AI coding agents Tenet tested are, in the strictest sense, best-of-class. They are not what a small business is using for support triage. If those agents fell to Agentjacking, the ones running in every SMB stack right now are not doing any better.

What To Do This Week

If you are running one or more AI agents in your business today, here is the sequence of steps that will most reduce your exposure. Every step is achievable in a normal workweek.

1. Inventory your agents' tools. For every agent you run, list the exact tools it can call. If the list includes any generic shell, generic HTTP fetch, or generic "run arbitrary code" tool, that is where the work starts. Replace generic tools with narrowly scoped ones for the specific tasks the agent actually does.

2. Inventory your agents' credentials. For every agent, list every credential it holds. For each credential, ask what the minimum scope for the agent's job actually is. Rotate any credential that is broader than the job requires and replace it with a narrower one.

3. Map the untrusted inputs. For every source of data your agent reads, mark whether the source accepts input from outside your business. Support tickets: yes. Internal notes from your ops manager: no. Calendar invites: yes. Company handbook: no. This map is the input to your escalation policy.

4. Add an escalation checkpoint for actions triggered by untrusted input. The agent can still read customer support tickets. The agent can still draft responses. But if the agent decides to take an action other than "draft a reply" based on the content of a ticket — for example, "issue a refund," "add a discount code," "update the customer's plan" — that action gets held for human review. The seam has moved by one step.

5. Confirm you have a runtime kill switch and a real audit trail. If either is missing, the vendor gap is your next problem to solve. Ask the vendor directly. If the answer is not a straight yes, the platform you chose is not runtime-governed. That is a decision, not a fact — you can change it.

None of these steps require technical genius. All of them require a business decision that the agent is now a piece of production infrastructure and needs to be operated as one.

FAQ

Q: Isn't runtime governance just enterprise security theater? Small businesses cannot afford this. A: The opposite. Enterprise security theater is compliance frameworks, audit committees, and policy documents. Runtime governance is code and configuration — a narrow tool allowlist, a scoped API key, an audit log, a kill switch. Every one of those is achievable on an SMB budget. What is expensive is finding out the hard way that your agent had a chainsaw.

Q: Does using a big-vendor agent platform protect me from this? A: Partially. Serious vendors are investing in runtime controls — Microsoft, Datadog, Anthropic have all announced work in this direction in July 2026. But no vendor can decide for you which tools your agent needs, how narrowly your credentials are scoped, or when to pause and ask a human. The runtime controls only work if you configure them. A great platform poorly configured is a bad platform in production.

Q: How does Agentjacking apply if I do not use coding agents? A: The Sentry-and-MCP part is specific to coding agents. The underlying pattern — hostile content injected into a tool your agent trusts, executed as instructions — is not. Customer support tickets, calendar invites, form submissions, uploaded PDFs, and email footers have all been demonstrated as injection surfaces. Any agent that takes action based on text it did not write is exposed to the same class of attack. The controls in this post apply across all of them.

Q: What's the fastest way to tell if my current agent setup is safe? A: Ask one question: "If a customer put a hostile instruction in a support ticket, what would my agent do?" If your answer is "I trust the system prompt to catch it," you have a behavioral safety posture. If your answer is "the runtime would block the action anyway because the tool is not available and the escalation policy would kick in," you have runtime governance. Most SMB deployments are in the first bucket. Getting to the second is a week of focused work, not a re-platform.

Q: Do I need to build all of this myself? A: No. The point of an agent operating layer is that these controls are built once, at the platform level, and inherited by every agent your business runs. That is the difference between wiring up a chat agent through a consumer AI product and running agents on infrastructure that was designed around the assumption that agents will be wrong sometimes and untrusted input will always exist.

The Bottom Line

Every serious industry actor spent the first week of July 2026 saying the same thing in different words. Microsoft is spending $2.5 billion to help enterprises operate agents. Datadog is buying a research team to build agent observability. Tenet Security is telling every developer that the only defense left is at the agent's runtime. The message is consistent: what happens around the model is now the interesting problem, and the businesses that treat it that way will pull ahead of the ones still hoping a better system prompt will do it.

Small businesses have an advantage here. There is no legacy platform to migrate off. There is no committee to convince. The decision to run agents on infrastructure that includes real runtime controls — narrow tools, scoped credentials, tagged inputs, real audit trails, and a working kill switch — is available today, at SMB pricing, on platforms built for it. The businesses making that decision now will not have to make the harder decision later, after the incident. That is the whole game.

At Associates AI, we build the operating layer that makes runtime governance the default rather than the exception. Every agent runs inside a persistent, controllable environment with narrow tools, scoped credentials, a real audit trail, and a runtime that pauses on untrusted input. If your business is ready to run agents on infrastructure designed for production instead of infrastructure designed for demos, start a free trial at associatesai.team.