Overnight, a retailer’s support agent issues hundreds of refunds. At a hospitality group, a guest-services agent comps dozens of rooms across the portfolio and reinstates loyalty points to match. Every action clears a standard business rule: valid order or reservation, plausible reason, amount under the threshold that would route it to a human. By morning, the pattern is obvious. It’s the same handful of accounts and the same edited complaint template, just executed at scale now. The agent had access to act, the instruction to resolve tickets, and no built-in logic to detect whether it was being farmed.
That’s not a bad prompt. It’s an autonomous agent calling a function that moved real money and value out of a live system, and it’s the same exposure whether the trigger was a careless request, a poisoned data source, or a fraud ring that figured out the fastest path to payout was an agent nobody was watching.
Which raises the question most security programs can’t answer: when an agent acts like that, who owns the identity, and can your SOC reconstruct the decision chain if asked?
The industry has spent two years building guardrails around prompts and outputs. But once an agent has tool access, the prompt is just the catalyst. The real risk lies in the non-deterministic chain of API calls, database writes, and system actions the model chooses on its own.
Refunds and comps are just the financial leaks that show up in the morning reporting. A procurement agent issues a PO to a vendor added last week; a property agent reassigns housekeeping access rights overnight, and no one notices until a guest complains. Same mechanism, same missing owner.
Every Agent Is a New Identity, Not Just a New Tool
Security teams already know how to govern identities. Employees, service accounts, and API keys each come with defined permissions and a named owner, and when something looks wrong, there’s an audit trail to pull.
Agentic AI doesn’t fit cleanly into that model yet. An agent authenticates and acts on the business’s behalf much the way a service account does, holding its own credentials along the way, but it rarely gets the same discipline around provisioning, review, and retirement.
This gap shows up in the data. Cloud Security Alliance research found 51% of organizations have no clear ownership model for their AI identities, with 16% not even tracking new AI credentials as they’re created,¹ and Gartner’s own survey puts a number on the same problem: “only 13% of organizations think they have the right AI agent governance in place.²”
The ownership question is harder to answer than it sounds. At most organizations, there’s no clean line from a specific agent back to a named owner, not because security leaders haven’t thought about it, but because the tooling and process to track it consistently still doesn’t exist. The data above shows just how common that shortfall is.
For a retailer or hotel group operating across dozens, hundreds, or thousands of locations, that same question doesn’t have one answer, it has a different answer for nearly every property and every system the agent touches. Spread an already-common shortfall across that many locations and the exposure isn’t hypothetical.
A workable starting point borrows from how mature programs already handle privileged service accounts: the business unit that requested the agent is the named owner of record, accountable for its scope and its renewal, while security owns the review cadence and the ability to shut it off. That split doesn’t close the whole gap by itself, but it gives every agent a name to call when something looks wrong, which is exactly what most programs are missing right now.
The Agent That Passed Review Isn’t the Agent Running Today
A human employee who starts acting outside their role tends to get noticed by a manager or a peer long before it becomes a real problem. An agent whose scope has quietly expanded is much harder to catch, because nothing about the org chart changes when it happens.
The underlying model gets updated, a new integration gets bolted onto the workflow, or someone tweaks a system prompt to fix an unrelated bug. Six months later, an agent that was scoped narrowly at launch has a materially different effective reach, without a single policy document ever being revised.
A one-time approval doesn’t hold up the way it might for a piece of static software. An agent’s behavior has to be watched on an ongoing basis rather than signed off once and left alone.
Gartner® projects that “by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur.³” The problem wasn’t invisible because no one was looking. It was invisible until it had already caused damage, and by then the fix meant pulling the agent, not updating a policy.
Retail and hospitality already run on seasonal staffing swings and high turnover, so tracking who has access to what is a familiar headache long before AI enters the picture. Layering an ungoverned population of agent identities on top of that only compounds it.
What This Means for Retail and Hospitality Security Teams
A few practical shifts follow from treating agents as identities rather than tools:
- Every agent needs an owner, a documented scope, and a permissions review cadence, the same way a privileged human account would.
- Runtime visibility matters more than design-time approval. In practice, that means logging which systems and data an agent actually touched in a given session and flagging anything outside its documented scope, not just recording that the agent ran.
- Multi-step agent actions need the same segregation-of-duties thinking applied to financial systems, so a single agent isn’t able to both authorize and execute a sensitive action unchecked.
- Incident response plans need an agent-specific playbook: revoking an agent’s credentials and freezing its ability to act while preserving its action log for forensics, rather than the standard steps built for an infected laptop or server.
- Multi-location operators need one inventory of agents across the whole footprint, rather than a separate, informal answer from every property or district.
Who Answers for the Agent
The real question isn’t whether agents are useful. It’s whether anyone can say, with certainty, who’s accountable when one of them acts, and whose name sits next to that decision when it matters, whether that’s a regulator, an auditor, or a customer asking why their account got locked.
For retail and hospitality organizations rolling out agents quickly, settle that question while the deployment is still small enough to trace by hand, before it scales past the point where anyone can trace a single agent’s actions back to a decision someone actually signed off on.
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.
