The Importance of Security in the Age of AI

AI agents are no longer novelty chatbots. They are operational systems with access to calendars, files, messaging, and infrastructure. That shift changes everything: the threat model is no longer “LLM hallucination,” it’s LLM‑driven compromise. The moment you give a model broad access to your system or credentials, you’ve turned arbitrary user input into a privileged control plane.

The current “wild‑west agent” model is fundamentally unsafe. If an architecture allows unconstrained tool access plus arbitrary user input, it is a prompt‑injection liability waiting to happen. The only safe path forward is structured execution, explicit permissions, non‑executable UI, and sandboxed runtime boundaries. Anything else is theatre.

The core problem: arbitrary input + unconstrained tools

There is no magic prompt that prevents prompt injection. A prompt is just a string. Any model that can be manipulated by untrusted input can be coerced into using whatever tools you give it. If those tools include shell, filesystem, or arbitrary network, you’ve built a weapon with a conversational trigger. You might get lucky for a while, but the architecture itself is the vulnerability. OpenAI openly admits this, there's no secret here and that's what's so scary about a lot of today's tools. They know and we know that the problem is there and that it is dangerous and yet a large number of people seems completely unbothered.

If you're a business, adopting any of these tools is truly creating a trojan horse scenario except you know the trojan is hidden in the horse just waiting for the right moment to strike and all you do is pray it doesn't. When did it become acceptable to run trojan horse software as legitimate solutions? The phase we're in right now is just absolutely mind blowing!

Many systems describe themselves as “local,” but what they often mean is “the gateway runs locally while the model runs in the cloud.” That is not a safety claim. A local gateway does not prevent exfiltration if the model can read secrets or call external APIs. “Run it on your own machine” is not a security model; it’s a liability model.

This is exactly the risk profile acknowledged by clawdbot / molt.bot. Their own security guidance emphasises broad permissions, shell access, and user caution, effectively saying: “we built the gun; you’re responsible for not shooting yourself.” You can read it directly in clawdbot’s security guidance and docs.molt.bot. That’s not a security strategy; it’s an admission the system is unsafe by default.

If your architecture allows:

untrusted input → LLM → shell / file / network

then you have built a prompt‑injection exploit vector. That is not hypothetical. It is inevitable. You don't need a security expert to see what is blatantly obvious and the prompt for me writing this post is an article I saw extolling how amazing clawdbot is and how it's changing the world. I don't want to shit on someone else's work especially when we're building something people may one day compare to it but the failings here are so egregious it hurts. I think it may even be because we may be compared to them why I'm a bit pissed. It creates a dangerous precedent that any (event remotely similar) products will be compared to as they've captured the imagination of many but is so obvious we'll get major security incidents with clawdbot as the root cause. It truly does a disservice to us as engineers contributes to the growing concerning use of AI, further eroding user confidence in these systems.

The supply‑chain warning signs (even without AI)

This isn’t a theoretical concern. We already have a long trail of supply‑chain incidents that show how fragile our tooling ecosystem is without AI agents:

• npm supply‑chain attacks that hijack popular packages and run malicious postinstall scripts (see Snyk’s report on the SHA1‑Hulud incident).
• malware campaigns that steal CI secrets and API keys from developer machines (see TechRadar’s coverage of npm package hijacking).
• poisoned dependencies and compromised workflows that silently exfiltrate credentials (see the GhostAction campaign).

Now take that same environment and add an LLM that can read config files and call outbound APIs. You haven’t just widened the blast radius — you’ve automated the blast.

Why “sandboxed iframes” are good — but not enough

Anthropic’s MCP Apps and the MCP‑UI ecosystem are steps in the right direction. They avoid raw DOM injection by running UIs in sandboxed iframes and communicating via structured JSON‑RPC (see MCP Apps and mcpui.dev). That is undeniably safer than arbitrary embedded webviews.

But it still executes third‑party HTML/JS. A sandbox is a mitigation, not a guarantee. It’s a smaller blast radius, not a different architecture. You still have executable code — just wrapped in extra precautions.

The safer alternative is declarative UI: structured JSON that renders into native controls, with no executable code at all. That is what A2UI provides. A2UI isn’t our invention; it’s a proven model that eliminates an entire class of “untrusted UI script” risks from the start.

What is Worka?

Worka is a secure AI operating system. It runs packs—sandboxed, versioned units of functionality—inside a WASM runtime. Packs expose structured tools (MCP), optional declarative UI (A2UI), and explicit capabilities and dependencies. The host mediates every action so there is always a place to enforce policy, audit behaviour, and keep data isolated.

In practice, this means:

• Packs can’t touch the filesystem, network, or hardware unless the host explicitly grants those capabilities. Even then, the since the host provides the APIs by which these are accessed, it can run standard, engineered security checks to detect and flag suspicious activity without LLMs
• UI is rendered from structured JSON (A2UI), not from third‑party HTML/JS.
• Orchestration is structured and auditable, not “prompt‑in, chaos‑out.”
• Secrets live in OS‑level secure storage, not plaintext files (or secure/encrypted DB based vaults).

Worka supports fully local execution for third‑party packs, and uses a cloud API only where it makes sense for first‑party verticals. The design is intended to make AI automation safe enough for real businesses—not just fun demos.

The only secure path forward: structured execution + explicit permissions

A secure AI platform must follow a few principles so fundamental they should feel boring:

First, third‑party code needs real isolation. That means a strongly sandboxed runtime — WASM or tightly controlled containers — where untrusted code cannot reach the host by default.

Second, every sensitive capability must be explicitly declared and enforced. If a pack can call the network or touch a device, that should be obvious and revocable, not implied by a model’s imagination.

Third, tools must be structured and schema‑validated, not shell scripts or arbitrary RPC calls. The moment you allow raw shell or free‑form network access, you’ve lost the plot.

Fourth, UI must be non‑executable. If you accept untrusted HTML/JS, you’ve imported the entire browser security problem into your agent system. Declarative UI — A2UI or any equivalent — removes that entire class of risk.

Fifth, actions must be host‑mediated and auditable. Packs should not reach out to the world directly unless the host explicitly allows it, because the host is the only place you can reliably enforce policy.

Finally, secrets must live in secure storage — OS keychains or encrypted vaults — never plaintext files.

This is the model we are building in Worka: a secure AI operating system designed for real‑world automation without turning users into security liabilities. It’s not a marketing position; it’s an engineering position. You can’t bolt this on later.

Why Worka’s approach isn’t just “better” — it’s required

Worka’s architecture is foundationally different. It uses a WASM sandbox to isolate pack code, explicit capabilities and dependencies to prevent silent privilege creep, A2UI to eliminate executable UI surfaces, and structured tool calls to remove prompt‑injection‑to‑shell execution paths. Secrets are stored using the OS keychain. Third‑party packs can run fully local; cloud is only used when necessary for specific first‑party verticals.

Is it perfect? No. But it is the only credible baseline. Everything else is gambling with users’ credentials, machines, and identity.

It still surprises me how much of the industry is accepting insecure systems knowingly — or at least through wilful ignorance. We’re throwing out decades of security practice and reenacting the late‑90s and early‑2000s internet, where everything was open, exploitable, and dangerous.

Conclusion

The current agent ecosystem celebrates power and convenience while sweeping security under the rug. That era must end. If AI is going to act on our behalf, it must do so inside strict guardrails, with explicit permissions, structured actions, and non‑executable interfaces.

If your platform does not enforce these properties, it is not safe. It is a prompt injection away from catastrophe.

We’re launching Worka in February 2026. If you care about safe automation and you’re tired of “vibe‑coded” agents with real access to your systems, join the waiting list at worka.ai. Engineering was never about writing code — it's always been engineering solutions with knowns and known unknowns giving you something you can measurably trust. Worka is an engineered solution.