It Doesn't Take a Hacker to Leak Your Data: How to Secure AI Agent Access in the Enterprise
It used to take a hacker to leak your data. That is no longer true. Connect an AI agent to your applications and it gets static access with broad permissions, often broader than the people who set it up. From that moment, the agent can move, expose, or delete data as part of its normal job. No attacker, no breach, just an agent doing what it was allowed to do.
That was the thread running through a recent session between Johannes Keienburg, Founder and CEO at Cakewalk, and Barbara Teruggi, an enterprise security architect who spends her days on exactly this inside some of the world's largest organizations. The two got into what actually changes when agents enter the access picture, why the threat model most teams still use was built for a different problem, and what a secure agentic setup looks like in practice.
Machine identities already outnumber humans by roughly 82 to 1 (CyberArk, 2025), and IDC expects more than a billion AI agents in production by 2029. Agents are being wired into enterprise stacks faster than any central team can govern them. The question Barbara kept returning to was not whether to adopt, but how to adopt without handing agents the keys to everything.
Key Takeaways
You do not need a breach to lose data. An agent with broad, static access can leak or delete it as a normal part of doing its job.
The everyday risk is quieter than an attack. People put data into agents that should never go near them, and shared agent workspaces expose it to everyone in the room.
An AI agent is a non-human identity with human capabilities. It has to be governed with zero trust, not with the permissions of the person who introduced it.
Default-deny is the right posture. Deny first, allow later, and let the agent ask permission for each job instead of inheriting a standing scope.
Credentials belong in a vault, brokered and short-lived, and the agent should never see them.
No single identity, human or agent, should be able to complete a full process from start to finish.
Data classification is now a daily discipline, not the training you click through once a year.
The Threat Isn't Only the Attacker Anymore
For most of security's history, the threat had a face. Outsider risk, insider risk, the malicious employee. Someone wanted to do you harm, and the job was to keep them out or catch them in the act.
Agents break that framing. An agent running autonomously with static access and broad permissions is a risk on its own, before anyone compromises it and before it turns malicious. It can simply decide that deleting a database, or sharing one, is part of the task at hand. Barbara's own summary of what worries her team was the line that reframed the whole conversation.
"We are concerned about attacks, but we are also concerned about how can we be the threat."
The point is that a leak no longer requires an intrusion. As she put it, it does not take an attack to leak something accidentally. It can be plain misuse, the organization doing it to itself. Someone from HR drops confidential PII or payroll data into a shared agent workspace, and suddenly everyone in that workspace can read it. The agent was never hacked. It just had access it should never have had.
The damage is not limited to data loss either. Point an agent at a code base and it can rewrite or delete parts of it. The blast radius runs wider than the old data-exfiltration model accounted for, because an agent can act on data where older threats mostly just read it.
An AI Agent Is a Non-Human Identity With Human Capabilities
So what kind of identity is an agent? Barbara's answer was precise, and it is the foundation everything else rests on. An agent is a machine, and it should be treated like one. But it is a machine that acts like a human, which means it can go unchecked and undetected if you are not careful, and it is a machine that can fail.
"It's a non-human identity, but with human capabilities."
That blurred boundary is what makes it hard to govern. A traditional non-human identity was strictly deterministic. It did one thing, the same way, every time. An agent has something closer to the freedom of a human. It improvises, and every so often it does something genuinely strange. Two things set it apart from a person, though: it acts at machine speed, and it carries no accountability or liability. You cannot sue an agent. That combination, human-like autonomy with none of the human consequences, is why neither human access control nor traditional non-human access control was built to govern it.
Which lands you at zero trust. An agent mimics a human, but it should never be mistaken for one, and it should be trusted with nothing by default.
Why Agents Shouldn't Inherit Human Permissions
The most common mistake in agent rollout is the quiet assumption that an agent should get the same permissions as the person who introduced it. Barbara's view on that was blunt: not by a mile.
Her analogy was the photo picker on your phone. You can see every image on your device, but when an app asks for access, you hand it a subset, and often a subset of that subset. The same logic applies to agents. Cloud IAM already lets you go granular, defining the exact conditions under which a process accesses a specific piece of information. Agents should be scoped the same way, with least privilege as the default rather than an afterthought.
The human behind the agent still matters as an input. It just isn't the ceiling. A CTO connecting Claude to GitHub should end up with very different entitlements than a junior sales rep trying to wire an agent into engineering environments, where the default answer should be no. The person is a signal that helps shape the scope, not the scope itself. What the agent can touch has to come down to the specific job it is doing, not the identity of whoever set it up.
This is the argument for dynamic, job-scoped access. The agent gets what the task needs, and nothing more.
The Case for Default-Deny Agents
If an agent should not inherit human permissions, what is the alternative? Barbara's rule of thumb runs the opposite way to how most teams operate. Deny first, allow later. Build an allow-list of permissions rather than starting from broad access and trying to claw it back.
She was candid about why this matters even for non-technical users. Most people are not organized enough to track what their agent can see and do at every moment, and honestly, few of us want to be. It gets messy fast. So rather than granting standing access and hoping for the best, she would rather the agent come back and ask.
"I prefer the agent to ask me, 'May I do this?'"
In practice that looks like a user separating what is safe for the agent to touch from what is not. This folder, yes. That folder with the contracts, no. The person stays conscious of what they are putting in each bucket, and the agent works inside those lines.
Who draws the lines is a shared responsibility. Leadership decides what is in and out of bounds. Technical and non-technical people translate that into data classifications and policies, then enforce controls on top. But Barbara was honest about the limits of policy on its own. Applying controls to agents can feel like "putting doors in an open field." Some judgment always falls to the end user, which is why the ground rules have to be spelled out in plain language and surfaced at the moment of the decision, not buried in a handbook. A well-designed policy engine is what turns those rules into enforcement instead of paperwork.
Keep Agents Away From Production
One line was non-negotiable for Barbara: agents doing developer, DevOps, or infrastructure work should be completely separated and segregated from production workloads.
Her reasoning drew on how privileged access already works for humans. To reach a sensitive server, a person does not just walk in. They go through a captive portal, hold a specific role, have their session monitored, and often need someone else present to approve what they do. If that is the bar for a human, an autonomous agent should not get a shortcut around it. She pointed to public incidents where an agent held access to production servers and caused damage, and her question was the right one: why did that access exist at all, and if it came from an employee's permissions, why did the employee have them either?
She also separated three things that often get lumped together: experimenting with AI in a controlled sandbox, running agents for everyday internal productivity, and putting AI inside one of your own products. Three different levels, three different sets of controls. Lump them together and scope creeps before anyone notices.
Where Agent Credentials Belong
Agent authentication is one of the least solved parts of the stack today. What usually happens is that a human hands over their own credentials to connect an agent to an MCP server or a third-party SaaS system. That static connection is the problem.
Barbara's model, drawn from how mature systems already handle secrets, is straightforward. Credentials belong in a vault. A broker retrieves them so the application, or the agent, never sees them directly. Tokens are short-lived and used just in time, then gone. For sensitive operations, you add another relay of authentication, the way a jump server issues a fresh set of keys you never actually see when you reach the end server.
"This credential should be completely transparent to them."
The security win is bigger than avoiding credential theft. With no static credential wired into the agent, the agent effectively has to apply for access on each job. That turns credentials into an enforcement point for governance: the agent only carries out the access it genuinely needs, in line with company policy, one task at a time. That is what credential mediation does, and it is the difference between least privilege on a slide and least privilege that actually holds.
No Identity Should Complete a Full Process Alone
Near the end, Barbara added a principle that sounds obvious until you sit with it.
"No human or non-human identity should be able to complete a full process. Never."
From a breach perspective, the reasoning is airtight. If a single identity can run a process end to end, then automating or compromising that one identity is enough to own the whole thing. Segregation of duties has always been the counter to that, and it applies to agents just as much as to people. She pointed to breaches where attackers rode an agent's broad access into a company's Google Workspace and expanded outward from there. One over-permissioned identity was the whole opening.
For agents, this means designing so that no single agent, and no single credential, can carry a sensitive workflow from start to finish without another control in the path.
Getting Started Without Trying to Be Perfect
None of this arrives fully formed, and Barbara was clear that perfection on day one is not the goal. She sees companies spread across a spectrum. Some refuse to touch agents until the fundamentals are in place. Others wire them in straight away and plan to fix the security on the go. Most land somewhere in the middle, picking a set of apps to allow, setting the ground rules, then tightening as they learn. The honest starting point for all of them is uncomfortable: most organizations have not fully brought human access under control yet, and now they are adding autonomous agents on top.
Her advice on where to begin came down to a few foundations. Network controls first, both the outer ring and internal segmentation, so exfiltration and infiltration are blocked by configuration and not just by policy. Enterprise accounts for the AI apps in use, with public AI blocked by configuration rather than by a line in a handbook. Constant monitoring down to the process level. And managed settings on the apps themselves, so risky actions can be denied or logged by default.
Then there is data classification, which she argued has changed character entirely. It cannot be the annual training you complete and forget. With agents, the boundary moves earlier: the risk starts before an agent accesses anything, at the moment a person decides what to feed it. You have to own your data and know what type you are handling, because that knowledge drives every downstream decision about what an agent should ever touch. Getting there starts with knowing what agents and AI apps are even in your environment, which is where agent and AI discovery comes in.
Should Agents Ever Run Without a Human?
Johannes closed by asking where all of this is heading. Twelve months out, could an agent become the first identity in the chain, getting access directly with no human involved, the fully autonomous workforce everyone keeps predicting?
Barbara's answer was a hope more than a forecast: she hopes it does not. And her reasoning is not nostalgia. We have already watched attackers subvert automation flows like GitHub Actions through supply-chain attacks, and agentic systems are nowhere near mature enough to be trusted with that kind of independence. What worries her more is the habit underneath it. We optimize for speed, we ship in less time, and we have been late to secure almost everything we have ever automated. Every round of optimization widens the attack surface, and with agents it does not just widen, it multiplies. Her conclusion was blunt: she does not think we need that level of automation in the first place.
For now the human stays in the loop, and not only as a technical control. Legally, the person who introduces an agent is still the one on the hook for what it does. An agent cannot answer for itself, so someone has to, and that is part of why the controls above are not optional. They keep a person accountable for a system that has no accountability of its own.
Govern Agent Access Before It Leaks
The uncomfortable truth from this session is that the biggest agent risk in most stacks is not a future attacker. It is the access already granted, sitting on agents nobody has reviewed, waiting to be used exactly as designed.
Stop handing agents your permissions. Cakewalk's AI Agent Access Management gives every agent its own identity, default-deny by policy, credentials it never sees, and a full audit trail of what it actually did.