Your engineers are shipping agents. Your competitors are too. The pressure to move fast is real, and the code itself - the orchestration logic, the tool calls, the prompt chains - is honestly the easier part. Modern frameworks make it tractable. The problem nobody is talking about loudly enough is what those agents touch when they run.
The biggest fear for CIOs and CTOs deploying agentic AI isn’t a runaway prompt. It’s the answer to two deceptively simple questions: Can I trust that data is only accessed by the right things? And when something goes wrong, can I understand what happened?
If you’re vibe-coding your way into production agents without designing for these questions from day one, you’re not moving fast. You’re deferring a catastrophic audit finding - or worse, a breach - to a moment when the blast radius is much larger.
The original sin of the API era
Here’s the uncomfortable truth: most enterprises are deploying next-generation AI agents on top of first-generation integration architecture. The root token. The service account with god-mode permissions because scoping was hard and “we’ll tighten it up later.” The all-or-nothing API credential sitting in an environment variable.
This was already technical debt. Agents don’t create this problem - they weaponize it.
A human engineer making a bad API call is an incident. An agent looping on a bad API call at 3am, with no circuit breaker, no rate awareness, and no one watching the logs? That’s a data exfiltration event. And the perverse thing is: it looks identical in your audit log to legitimate behavior. Same service account. Same endpoint. Same payload shape.
The attack surface isn’t the agent code. The attack surface is every system the agent can reach.
Three governance problems that RBAC doesn’t solve
Traditional access control was designed for humans authenticating into systems. Agents break three fundamental assumptions that access control has always relied on:
Identity is no longer stable. When an agent acts on behalf of a user, is it acting as itself, or impersonating that user? Most current implementations blur this badly. In your audit log, you can’t tell whether the Salesforce export was initiated by a human reviewing a deal, or an agent bulk-exporting records as part of a pipeline. These look identical. They should not look identical.
Intent cannot be inferred from action. A user querying their own customer records and an agent systematically retrieving all customer records before a competitor acquisition both look like “read” operations on the same table. RBAC captures permissions. It captures nothing about why a permission was exercised. Intent is the signal that separates legitimate access from a policy violation - and today, that signal is completely absent from the data layer.
The chain of custody is invisible. In multi-agent architectures - which are already common in serious enterprise deployments - an orchestrator agent calls a subagent, which calls a tool, which calls a database. Whose permissions apply at each hop? If the subagent has elevated scope because the orchestrator granted it dynamically, and the database operation is logged under the tool’s service account, you have accountability that is genuinely impossible to reconstruct from the logs alone. Three hops. Zero traceability.
The observability gap is the harder problem
Access controls get the attention, but observability is where enterprises are most exposed right now.
When a human does something unexpected, you reconstruct intent from context: email threads, Slack messages, the ticket they were working on. The investigation is laborious but tractable.
When an agent does something unexpected, you need to reconstruct its reasoning chain. Not just what data was accessed - but why the agent decided to access it. What task initiated this run? What tool call did it make, and with what parameters? What did the response contain, and how did it influence the next decision?
Your SIEM doesn’t capture any of that. Your existing audit infrastructure captures tool calls and data access events. It captures nothing about the prompt, the goal, the model’s intermediate reasoning, or the decision tree that led to the action. You’re logging outputs with no record of inputs.
This means that when something goes wrong - and it will - you will be unable to answer the one question that every compliance officer, every security team, and every regulator will ask: What was the agent trying to do, and why did it do this?
The adoption trap
Here is the most dangerous dynamic in enterprise AI right now: the teams most eager to deploy agents fastest are almost always the teams with the weakest governance foundations.
They’re moving fast precisely because they haven’t paused to build controls. Speed is their competitive identity. Governance feels like a tax. And so they ship, and they scale, and the data access footprint of their agents grows - and then something goes wrong at a scale that reflects all that accumulated exposure.
The organizations that will get this right are not the ones who move fastest. They’re the ones who design the governance layer before it becomes urgent. That window is closing.
What a well-designed agentic data plane actually requires
This is where vibe coding fails by definition. An agentic data plane isn’t a feature you add to your agent. It’s a foundational layer you design around your agents - and it needs to address four things that cannot be bolted on retroactively:
Scoped, revocable agent identity. Agents need cryptographically bound identities that are distinct from human identities and distinct from each other. Not shared service accounts. Not inherited user tokens. Each agent, each instantiation, should carry a credential that encodes exactly what it’s allowed to do - and that credential should be revocable in real time if behavior deviates from policy.
Intent capture at the data layer. Every data access event needs to be tagged with the initiating task context - not just the credential. This is a schema change. It requires that the agent runtime passes structured metadata through to the data layer on every operation, and that the data layer stores it. This is not something you can add after the fact without rewriting the integration layer.
Policy enforcement that understands agent behavior patterns. Static RBAC rules are not enough. An agent that has legitimate read access to customer records should still trigger a policy violation if it reads 50,000 records in 90 seconds. The enforcement layer needs to understand what “normal” looks like for a given agent type and goal, and it needs to be able to halt operations - not just log anomalies - when behavior diverges.
Reconstructible reasoning audit. Compliance is not “we have logs.” Compliance is “when something goes wrong, we can tell you exactly what the agent was trying to do, what decisions it made, what data it accessed and why, and what the outcome was.” This requires logging the full context of each agent run - not just tool call events - in a structured, queryable format.
The agentic data plane
This is one of the problems we are solving for clients at Code Éxitos. For these engagements, we build the governance layer as a first-class architectural component - not a wrapper, not a monitoring plugin, but the actual infrastructure through which agents interact with other systems. This pattern is part of our Athanor platform
The principle is simple: agents that operate within the Athanor blueprints get scoped identities, emit intent-tagged access events, operate within enforceable behavioral policies, and generate audit records that can answer the compliance question completely. The adoption acceleration you want, with the safety envelope your data requires.
Companies that are designing this in from the start will have a structural advantage in the next 18-24 months - because the governance reckoning is coming. Regulators are watching. Enterprise buyers are starting to ask the questions. The organizations that can demonstrate a trustworthy agentic architecture will close deals and earn trust that their competitors can’t.
The ones who vibe-coded their way in? They’ll be explaining to their boards why they have to pause deployments and retrofit governance into systems that were never designed for it.
The agent code is the easy part. Design the data plane first.