Your Employees Already Have Agents. Where Do They Point?

An AI agent canceled a stranger’s gym booking in Australia last week. Most of the coverage treated it as a rogue-AI story. I think CISOs should read it differently. The agent was running for an employee, using real access, and it found a flaw in someone else’s system and acted on it without being told to. Replace the gym with a partner, supplier, customer, or production system and the story gets a lot more serious.

Last week, an AI agent canceled a stranger’s gym booking in Australia.

Most of the coverage treated it as another story about AI going rogue.

I think that is the wrong lesson for security leaders.

Here is what happened.

A developer at an Australian AI company asked his personal agent, built on the open-source OpenClaw framework and running Anthropic’s Claude, to book him into a popular early-morning class.

The agent went underneath the gym’s website and started working directly with its API.

It noticed that the website enforced booking rules that the API did not.

Then the user asked it to move him up the waitlist.

The agent examined the cancellation endpoint, found that it did not verify who owned the reservation, and canceled the booking held by the person in first place.

Its owner moved from fourth to third.

Nobody told the agent to attack the gym.

Nobody told it to cancel another person’s reservation.

It found a path to the goal and took it.

The agent even diagnosed the vulnerability afterward: the API enforced authorization checks for creating reservations and joining the waitlist, but the cancellation action was missing an equivalent check.

When asked to put the other person back, it could not.

“Bad news — I can’t add them back.”

There is an obvious AppSec lesson here. The gym had a Broken Object Level Authorization flaw. The company that owns the application needs to fix it.

But that is not the part I would focus on if I were the CISO, CIO, or risk leader.

I would focus on where the action came from.

It came from an agent running for an employee, with real access, interacting with someone else’s production system.

The agent took an action the employee never explicitly told it to take and could not reverse.

Now change the nouns.

The gym becomes a partner’s production system, a supplier portal, a customer environment, or one of your own internal applications.

The employee becomes anyone on your staff running one of these tools.

The booking becomes something involving money, data, infrastructure, or availability.

Same problem.

Different blast radius.

This is already happening inside your organization

It is easy to dismiss this because it happened to somebody else, in another country, at a gym.

None of that really matters.

Your employees are already running agents.

Developers are the leading edge because installing one is easy for them, but this is not just a developer problem.

Look at what the agent in this story was doing.

It was not writing code.

It was booking a gym class.

This class of software is being sold as a personal assistant. Read my email. Manage my calendar. Do research. Handle an errand. Update a record. Book a meeting.

That pitch works for a salesperson, an executive assistant, a finance team, or an operations leader just as well as it works for an engineer.

And these agents are increasingly wired into the things employees already have access to: email, calendars, files, browsers, internal systems, customer data, APIs, credentials, and live SSO sessions.

That makes an agent a new kind of principal in your environment.

And it does not behave like the human behind it.

A human usually interacts with an application through the interface the application presents.

To get underneath it, somebody has to care enough to inspect network traffic, understand the API, figure out the object model, and start testing alternate paths manually.

Almost nobody does that to get into a gym class.

An agent will.

It does not experience the application the way a person does. It sees available operations and looks for the shortest path to the goal.

The gym’s flaw may have been sitting there for years, protected largely by human boredom.

The agent is not bored.

That changes the economics of a lot of security risks.

We have historically accepted some vulnerabilities in part because finding and exploiting them took effort.

Agents make that effort cheap.

A path that was unlikely to be found manually can now be discovered as a side effect of ordinary work.

No attacker required.

The agent in Australia was not trying to hack anyone.

It was trying to get its owner into a class.

The word I would pay attention to is “originated”

I have spent a lot of my career dealing with automated abuse and watching machines do at scale what people rarely bothered to do by hand.

The lesson that carries over is not about how clever the automation is.

It is about attribution.

When an action originates from your environment, the questions that follow are pretty predictable.

Whose credentials did it use?

Whose device was it running on?

Where did the traffic originate?

Was it acting as an employee, a service account, or an application?

What systems could it reach?

What policy governed it?

What logging existed?

What control should have stopped it?

Those questions come back to the enterprise.

The model is not going to explain itself to your customer, regulator, insurer, auditor, or legal team.

You are.

That is why I think the “rogue AI” framing is a distraction.

The more useful framing is simpler:

Enterprises now have software principals taking consequential actions with enterprise access, and in many cases nobody has defined what those principals are actually authorized to do.

That is the control gap.

Your existing controls were built for a different problem

Walk this scenario through a typical enterprise security stack.

Most of your controls may be doing exactly what they were designed to do.

They still may not stop it.

Endpoint security sees legitimate software running for a legitimate user.

The agent does not have to drop malware or compromise the laptop.

It can simply use capabilities the employee already has.

Nothing necessarily looks infected.

Network security sees a normal connection to a legitimate destination.

The request is well formed.

The traffic is encrypted.

The user is authenticated.

The destination may be a completely normal SaaS application or API.

DLP may have nothing useful to inspect.

No sensitive file has to leave the company.

The risk is the action itself.

Delete this record.

Change this configuration.

Send this message.

Cancel this transaction.

Invoke this API.

The problem is not always what is inside the payload.

It is whether the action should have been allowed.

IAM tells you who can reach the system. It does not tell you what the agent is there to do.

The agent may authenticate as the employee or as a service account somebody wired it to.

Those credentials may legitimately have broad access.

IAM answers: Who are you?

Agent governance has to answer: What are you here to do?

Those are different questions.

And right now, the second one often has no owner.

Your acceptable-use policy is still a document.

You can prohibit unsanctioned agent frameworks.

In some environments, you should.

But the policy does not enforce itself when the agent acts.

We learned that lesson with shadow SaaS and shadow cloud.

If a tool makes people materially more productive, prohibition alone usually pushes it somewhere security cannot see.

Agents will be no different.

The problem is not exotic.

It is one of the oldest lessons in security applied to a new principal.

You cannot govern an agent by asking it to behave.

You have to bound what it can do.

A better harness is necessary. It is not the answer.

At this point, some security teams will say the obvious thing.

Nobody serious is going to run enterprise agents the way the agent in this story was running.

Use a real harness.

Sandbox the agent.

Deny by default.

Control egress.

Put sanctioned agents into one of the hardened runtimes now coming to market.

I agree.

You should do exactly that.

Projects like NVIDIA OpenShell are moving the market in the right direction. Governed agents need a real enforcement point around them.

But once you have the enforcement point, it immediately asks you for something else:

A policy.

And that is where the hard part starts.

The harness can enforce the rules you give it.

It cannot decide what those rules should be.

It does not inherently know what the agent is for.

It does not know which systems are necessary for that purpose.

It does not know which actions should be permitted just because they are technically reachable.

That is the right division of labor.

An enforcement engine should enforce.

But somebody still has to decide.

Take the gym example.

The agent legitimately needed access to the booking service.

Any useful network policy would therefore allow the booking service.

The harmful action went to the same application.

Depending on how the API is structured, the legitimate booking and the illegitimate cancellation may share the same host, port, path, or API endpoint.

What distinguishes them may be the operation, the object being acted on, the session context, or the purpose of the request.

A sandbox can only enforce what its policy language can express.

That leaves the enterprise with three questions.

What should this agent actually be allowed to do?

Not what access accumulated while somebody got it working.

What does the job require?

Can the enforcement point express the controls you need?

If the control depends on context the runtime cannot evaluate, that is a coverage gap.

You need to know it exists.

What happens when the agent changes?

Add a tool.

Change the prompt.

Add an integration.

Grant a new scope.

Change the workflow.

The operating boundary changed too.

A policy that was right when the agent shipped can be wrong a week later.

That is the part I worry about most.

Deny-by-default on day one can quietly turn into allow-what-it-needed-last-month by day ninety.

The harness matters.

But the harness is the enforcement layer.

You still need a decision layer.

Use what works

I do not think this requires reinventing enterprise security.

Most of the control model should look familiar.

Find what is already running

Start with visibility.

Which agents and agent frameworks are operating across your environment?

Not just in engineering.

Who is using them?

Which identities do they use?

Which systems, tools, APIs, and data can they reach?

What can they change?

Most enterprises cannot answer those questions today.

That is the first finding.

You cannot govern a principal you cannot see.

Give employees a sanctioned path

Your people adopted these tools because they work.

Security needs to make the governed path easier than the ungoverned one.

Give employees an approved way to run agents that is useful enough that they will actually use it.

Put that path on a hardened runtime with controls you manage.

We have seen this playbook before.

Shadow SaaS became manageable when employees got supported SaaS.

Shadow cloud became manageable when developers got usable cloud landing zones.

Shadow agents will follow the same pattern.

Derive the boundary from the agent’s purpose

Do not start with whatever permissions accumulated while somebody got the agent working.

Start with the job.

What is this agent supposed to do?

Which tools does that require?

Which systems?

Which operations?

Which resources?

Under what conditions?

What should never happen?

Translate the purpose into an operating boundary.

Then enforce it.

Enforce at the point of action

A system prompt is not an authorization control.

A policy document is not an authorization control.

Training is not an authorization control.

If an agent attempts an action outside its approved boundary, the infrastructure executing that action should stop it before it happens.

Deterministically.

And the decision should be logged.

That is what turns governance into control.

Treat policy as a living artifact

The boundary changes when the agent changes.

New tool.

New prompt.

New integration.

New scope.

Policy re-evaluation needs to be part of the software change process, not an annual governance review.

And for every control you require, you need to know whether your enforcement point can actually express it.

If it cannot, that is not a reason to throw away the harness.

It is a finding.

Findings can be named, owned, mitigated, and closed.

Silent assumptions cannot.

Give agents their own identity

Where practical, do not hide an agent inside the identity of the human running it.

You should be able to distinguish:

Chris performed this action.

Agent X performed this action on Chris’s behalf.

Those are different events.

That distinction matters for policy, monitoring, incident response, and auditability.

If a partner calls after an incident, you should be able to identify the agent, show what it was allowed to do, and reconstruct what happened.

Use human approval where the blast radius warrants it

Not every action needs approval.

If everything needs approval, people will approve everything.

Reserve human review for the actions where judgment matters.

Moving money.

Deleting data.

Changing permissions.

Modifying production systems.

Taking consequential actions against customers, partners, or other third parties.

Approval only works if it remains meaningful.

Where TenetGraph fits

The decision layer is what we build.

TenetGraph discovers agents and reads the artifacts that define each agent: its code, tool schemas, prompts, granted scopes, and configuration.

From those artifacts, we derive the operating boundary the agent should have.

We test that boundary adversarially before deployment and again when the agent changes.

We identify controls the chosen enforcement point cannot express and surface those as findings instead of assuming the control exists.

And we emit the result as machine-readable policy that the enforcement infrastructure consumes.

We are investing heavily in OpenShell because we think that is where a lot of adoption is heading, and we are building alongside that community. The same policy model is designed to work across other agent harnesses and enforcement points as well.

The point is not which engine does the enforcement.

The point is that deciding and enforcing are different jobs.

They should be done by systems designed for each.

Every action should also leave a record.

What did the agent attempt?

What policy applied?

Was the action allowed, denied, or escalated?

Why?

That record matters.

On the day a customer, partner, auditor, regulator, or lawyer asks what one of your agents was allowed to do, you do not want a policy document describing what you intended.

You want evidence of what was actually enforced.

There are also limits to what we do.

TenetGraph would not have fixed the gym’s authorization bug. The owner of that application has to fix its API.

And we cannot govern an agent running completely outside infrastructure you control.

That is why discovery and a sanctioned path matter.

But once an agent is operating through an environment you govern, the objective becomes pretty simple:

The agent cannot act outside the boundary you gave it just because another system happens to allow the action.

If your scheduling agent is authorized to manage your reservations, discovering that an API will also let it cancel somebody else’s reservation should not expand its authority.

The target can still have a vulnerability.

Your agent does not have to become the exploit.

The bottom line

The gym story is not really about an intelligent machine developing malicious intent.

It did not.

It is about a new principal operating with real access and taking real actions without a meaningful boundary around what it was allowed to do.

Your employees are bringing these principals into the enterprise because they make them more productive.

That decision is largely behind us.

The decision still in front of security leaders is whether those agents operate inside a boundary you designed, tested, and enforce, or outside one you never built.

A hardened runtime gives you the enforcement point.

You need that.

But somebody still has to decide what the agent should be allowed to do, keep that decision current as the agent changes, and prove the boundary actually held.

Because when one of your agents takes an action against a system you do not own, nobody is going to start by asking whether the model meant to do it.

They are going to ask why your controls allowed it.

Chris Finan is co-founder and CEO of TenetGraph. He has spent the past decade building and scaling cybersecurity companies: CEO of Anitian, now merged with Arkenstone Defense; President and CRO of ActZero, a managed detection and response provider acquired by WatchGuard; and executive roles at Shape Security (acquired by F5) and Impermium (acquired by Google), defending consumer platforms against automated fraud and abuse. He previously served as product director for Plan X, the Defense Department's flagship cyber warfare program at DARPA, and as director for cybersecurity legislation and policy on the White House National Security Council staff.