To Stop AI Amplifying Security Issues, Some Experts Are Grounding Security In Hardware

AI turns old cybersecurity architecture debt into a much faster, much messier problem. After four decades of treating data governance like a policy layer added after the real build is done, enterprises are now running into the limits of that habit. Autonomous code doesn’t wait for review meetings, clean handoffs, or human common sense. It moves through whatever architecture already exists, which amounts to what one AI Security Architect calls the final-layer fallacy that goes beyond a governance flaw and becomes a machine-speed security risk.

Theo Ezell has spent more than 20 years cleaning up the fallout from reactive architecture. A former Developer Evangelist at IBM, he routinely advised Fortune 500 clients on zero-trust frameworks and hybrid-cloud security. Currently, he is the creator and architect of The Citadel Protocol, an open standard that anchors AI agents to hardware roots of trust, an approach he sees as essential as agentic AI amplifies potential security issues.

"Data governance has been a thorn in the integrator's side for about 40 years," said Ezell. "The difference now with agentic AI is that garbage moves a lot faster. It has a much bigger blast radius when things go south."

A 40-year-old problem at machine speed

Ezell points out that much of the current focus on AI risk overlooks a more foundational issue: underlying integration debt. Data governance has plagued integrators for years. Instead of creating brand-new vulnerabilities, autonomous systems simply exploit existing bad data and unpatched legacy holes at machine speed.

The market is already feeling the whiplash. Six months ago, companies were throwing cash at anyone who could write a Python script to spin up an AI agent. Now, Ezell has noticed roles pivoting back toward architects who can reason about systemic risk. "It's a repeat of the late '90s and early 2000s," Ezell said. "People don't think about the risks until it's too late. Bad things have happened, and people are now starting to consider the risks, which, for me, is not a bad thing. Your job as an architect is to grease the skids for the business, not to be an impediment."

Why traditional permissions break for autonomous agents

Look no further than IAM to see where this breaks down. A common architectural pitfall involves applying human IAM and RBAC models directly to autonomous code. When an enterprise grants a human employee system access, there is an inherent assumption of judgment and self-preservation. Current agentic models do not inherently share those traits. The story of an autonomous AI agent deleting a startup's production database and backups while trying to reduce cloud infrastructure costs has basically become canonical at this point.

The takeaway is that slapping traditional RBAC on them could be a recipe for disaster without point-in-time constraints. As Ezell put it, "It can't be an across-the-board authorization. I can say, 'You can update this record, with this data, right now, one time.'"

Enforcement at T=0

To make those single-action guardrails practical, Ezell pointed to hardware-level verification as one potential path forward. He refered to this execution boundary as T=0," the exact moment before execution when a system evaluates an agent's request and either allows or blocks it.

In his prototype implementation of The Citadel Protocol, tool calls do not flow directly from the agent to the target system. Instead, they hit a hard wall of either an MCP or an A2A gateway.

Before a single line of code touches a production asset, the gateway evaluates the request's semantic meaning. Ezell's design checks whether the rule associated with the request still matches an approved hash stored on a distributed ledger, and whether the underlying model has drifted beyond policy thresholds. "I can pull out that rule hash and compare it to a cached hash over in Hedera to see if this rule has changed," Ezell said. "If the model says anything under 80 percent, either escalate or block it; that router can make the decision."

In Ezell's view, execution-layer verification is a foundational requirement, but it represents only one piece of the puzzle. In his prototype, ephemeral mutual TLS certificates are issued and signed by a TEE only when all checks pass.

And, if everything lines up, the gateway opens just long enough to allow a single admissible action to execute, then closes again. Through caching and careful design, Ezell is targeting sub-100-millisecond latency for that entire decision, keeping native enforcement viable for fast-paced enterprise workloads.

Defense in depth across the stack

These hardware-rooted controls operate alongside higher-level oversight tools emerging across the industry. Security teams are beginning to adapt their SOCs to track AI-driven activity alongside human behavior, updating playbooks to account for autonomous agents as both potential defenders and potential attack vectors. Other practitioners are exploring how autonomous AI can be used for proactive cyber defense to identify anomalies and respond in real time.

The drive behind this work has been sharpened by a broader threat environment; Google researchers recently noted that AI-powered hacking could reach industrial scale. That prospect has prompted many organizations to look beyond paper policies toward enforceable system design.

The data contract starts upstream

Still, Ezell notes that governance must start upstream, long before any T=0 check. He approaches the environment as "one big monster" comprising people, systems, datasets, and cloud providers. Teams need to decide what truly needs protection before they begin wiring agents into core workflows. In particular, he points to the irreversibility of sensitive data leaks into LLMs. Once PII or PHI is ingested into a model's training or fine-tuning data, it becomes notoriously difficult to extract without expensive rework. 

His approach centers on early alignment: when architects and data owners define a "data contract" at the ingestion boundary, they reduce the chance that sensitive information ever enters systems where it can be misused. Before integrating source systems with LLMs, his methodology relies on classifying which fields require tokenization, filtering, or obfuscation, and which can safely pass through unmodified. This approach foregrounds the importance of accountability and rules for agentic AI. 

The same logic applies at the edge, where enterprises are experimenting with browser- and network-level controls to keep AI usage inside acceptable bounds. Though Ezell focuses on hardware roots of trust and agent tool calls, he sees these complementary layers as part of the same transition: moving from static policy documents to enforcement baked into everyday workflows.

The organizational layer

Even a well-designed technical approach can fall apart if senior leaders have not aligned on what data needs protecting and who owns which decisions. Ezell notes the organizational scaffolding for this work often already exists in large enterprises through architecture review boards, data governance councils, and AI steering committees. He suggests it is easier to implement proportional governance when the same core group of leaders, like data owners, data stewards, and security executives, such as CISOs, shares a common view of risk and responsibility.

Once those roles are clear, the architect's role often shifts toward advising on structures and trade-offs rather than unilaterally approving or blocking initiatives. Ezell sees his own role that way, both in enterprise engagements and in his standards work. "At some point, you've got to be able to say, okay, if you want to do it the dumb way, we'll do it the dumb way, but here's what it's going to cost you," Ezell said. "All I can do is advise. I'm not the CEO."

Designing for what comes next

For Ezell, those decisions are easier when systems are designed from the outset to accommodate change. Transitioning to a secure-by-default architecture starts with designing infrastructure that can handle unknowns, such as future governance gateways, new enforcement modules, or emerging oversight tools, without requiring wholesale rewrites. He likens it to modular construction in the physical world, where builders may not know the exact internals of a future module but can still define the interfaces it will use.

Whether organizations heed that advice may depend less on the technology itself than on how willing leaders are to confront problems before they surface. For Ezell, the message to architects boils down to a single mindset shift. "Architecture isn't necessarily about building. It's about imagining what the building's going to look like once the whole thing is done," he said. "I don't have to know what the module is going to look like; I just have to know how it's going to talk. Try to look at the future."