The adoption cycle of new technologies tends to follow a common pattern. Some new, genuinely powerful capability emerges and people get excited. The use cases are still forming, so no one is exactly sure what to build yet. They jump on the bandwagon and rush to build infrastructure around it while the attention is there, hoping to catch the wave of popularity. Core principles like security and ownership are often treated as problems to be solved later, once things are more stable. Then it’s later…they’ve been lucky, the infrastructure is broadly in use, and now retrofitting is much harder than building it the right way would have been.
I think we’re approaching that moment with AI agents.
Agents are not new, but they are fundamentally changing in the year of the Claws. Their range of actions was initially quite limited, but now they are becoming complex systems that can hold credentials, retain context across sessions, call APIs, manage workflows, and take consequential actions on behalf of users. But most of the infrastructure they’re running on was not designed for this—it was built when the agentic ecosystem was much more primitive. And that is becoming a problem.
Security as a structural problem
When an agent has a credential, it needs to use that credential in order to be useful. The obvious way to make that work is to expose the credential to the model as context. That’s how most current systems are designed. But this is exactly the wrong way to do it.
If a secret lives in the model’s context, it can be extracted—through prompt injection, compromised tools, or a manipulated webpage the agent is browsing on the user’s behalf. The architecture is the attack surface, not the model’s alignment.
The same mistake happened with passwords on the early internet. Credential management was a hard problem, so builders took the quick and easy solution and moved on. We’re still paying for that shortcut. AI agents are going to have access to much more than web accounts, to financial systems, enterprise workflows, proprietary data, and real-world infrastructure. Getting the security model wrong this time is not a recoverable mistake.
For individual users, privacy is at stake. For enterprises, it makes agentic AI a nonstarter. Businesses have compliance requirements around customer data, IP they can’t expose to inference providers, and critical workflows where a credential leak or a misdirected tool call has legal and financial consequences. They can’t just assume that the models will work as they’re instructed to; we’ve already seen way too many examples of the failure points.
What IronClaw does differently
IronClaw is a secure runtime for AI agents built in Rust. The core design principle is simple: agents should be able to use credentials without ever exposing them. That means credentials live in an encrypted vault and are injected only at the host boundary, for pre-approved endpoints, never as plain context to the model. Tools run in isolated WebAssembly environments with explicit, scoped permissions. Network access is allowlisted. Outbound traffic is monitored for credential leakage and exfiltration. Memory safety is enforced at the system level.
None of this is very complicated. But the difference from other harnesses is that IronClaw treats security as a fundamental requirement in its architecture, not a layer tacked on at the end. Most of today’s agentic infrastructure does not. An enterprise deploying agents across financial workflows or customer data pipelines needs to know that the runtime can actually be audited. Security is enforced by the architecture, not a promise written into a policy.
IronClaw runs inside trusted execution environments on NEAR AI Cloud, with hardware-enforced isolation that protects data in memory and keeps credentials sealed off from the cloud provider. That works alongside the broader NEAR AI stack—including end-to-end encrypted inference and NEAR Intents for agentic commerce and cross-chain execution—which, combined, form an infrastructure layer designed for verifiable privacy. Every inference produces a cryptographic attestation that the correct code ran on the correct data. That verifiability is what makes the privacy claim actually auditable, and not just a claim.
When you combine confidential execution with per-tool sandboxing, strict network permissions, and credential isolation, you have a runtime where security properties can be verified rather than just assumed. That’s a meaningful distinction for any organization deploying agents in environments where the stakes are real.
Why NEAR
The vision for everything we’ve built on NEAR since 2018 has been to ensure that users are in control of their own data, assets, and decisions. Any digital system worth using at global scale will enhance, rather than erode, this model of user ownership.
This is what I mean when I talk about user-owned AI. It’s not just who owns the product. It’s about who controls the data, the context, the credentials, and the infrastructure the agent runs on. If the model provider, the cloud provider, or the application layer can see everything and change the rules, then the system is not aligned with the user. This is bad for everyone, but for enterprises, it’s a real liability.
The only way for agents to be truly useful is if they have full context. The only way companies can give agents full context is if they have guaranteed privacy. The value of an agent is proportional to how much it knows. Privacy is a requirement for the agent knowing enough to matter. Without it, businesses will continue interacting with AI at arm’s length, withholding certain data and context that would take it from a capable tool to a transformative one.
Secure by design
We are at the point where the infrastructure choices we make now will determine what is possible later. If agents are going to operate with meaningful context and permissions inside real systems, those systems need to be designed for security from the beginning—not retrofitted when the stakes become obvious. A stateless agent that gets compromised is inconvenient, but a security failure in an always-on agent with memory, credentials, and access across systems can cause serious damage. The agentic economy can only take shape if the agents are secure.
Bounded permissions; data isolation; confidential execution; verifiable behavior: that is what IronClaw on NEAR is built to provide, and it’s the foundation for building user-owned AI for enterprises at scale.
■ overview
May 5, 2026
NEAR Co-Founder Illia Polosukhin on why AI agent infrastructure must be secure by design, and how IronClaw on NEAR makes security verifiable.
key points
- The model context is the attack surface. Most agent infrastructure exposes credentials by passing them straight into the model's context, which turns prompt injection, compromised tools, and manipulated webpages into structural vulnerabilities rather than alignment problems.
- Security has to be enforced by architecture, not policy. IronClaw seals credentials in an encrypted vault, sandboxes tools in WebAssembly with scoped permissions, allowlists outbound network traffic, and runs inside hardware-isolated TEEs on NEAR AI Cloud, with cryptographic attestations that make every inference verifiable.
- Verifiable privacy is the precondition for valuable agents. An agent's value scales with how much context it has, and enterprises won't grant full context without guaranteed privacy. Without secure-by-design infrastructure, agentic AI stays a capable tool rather than a transformative one.