Beyond Tokens: Why the Future of Software Security is Capability Computing

UpdatedAugust 5, 2026

• 2 min read
• View as Markdown

Sangam Biradar

DevRel at StackGen | Formerly at Deepfence ,Tenable , Accurics | AWS Community Builder also Docker Community Award Winner at Dockercon2020 | CyberSecurity Innovator of Year 2023 award by Bsides Bangalore | Docker/HashiCorp Meetup Organiser Bangalore & Co-Author of Learn Lightweight Kubernetes with k3s (2019) , Packt Publication & also run Non Profit CloudNativeFolks / CloudSecCorner Community To Empower Free Education reach out me twitterhttps://twitter.com/sangamtwts or just follow on GitHub -> https://github.com/sangam14 for Valuable Resources

div>p:first-child]:mt-0 [&>div>p:first-child]:pt-0 min-w-0 wrap-break-word [&_a]:break-all **:max-w-full">

Over the past few decades, we've fundamentally changed how software is built. We moved from assembly to high-level languages, from monolithic applications to containers, and now from human-written code to AI-generated software.

Yet One Question Remains Surprisingly Unanswered

What is this software actually capable of doing?

Today's compilers optimize programs for speed, size, and correctness. Runtime security platforms monitor behavior after deployment. Policy engines decide who can access what. But there is no unified system that understands software capabilities as a first-class concept during compilation.

I believe the next evolution is Capability Computing.

Imagine a compiler that doesn't just understand instructions like load, store, or call, but instead reasons about higher-level capabilities:

• Filesystem.Read
• Network.Send
• Process.Execute
• Secret.Read
• Cloud.Create
• AI.Tool.Invoke

Instead Of Optimizing Only Machine Code, The Compiler Builds a Capability Graph That Represents What a Program Is Permitted To Do. Security Policies Can Then Be Verified Before Deployment, Producing Deterministic Decisions

• ALLOW
• DENY
• ESCALATE

The output is not only a binary, but also a signed capability manifest that any runtime—whether a microVM, WebAssembly runtime, or cloud platform—can enforce.

This shifts security from reactive monitoring to proactive verification.

More importantly, this approach is independent of how software is created. Whether code is written by a developer, generated by an AI model, or produced by another compiler, the verification process remains the same because it operates on capabilities, not tokens.

In this vision, LLVM, MLIR, WebAssembly, and future compiler infrastructures become frontends. Different sandbox technologies become runtimes. The stable abstraction in the middle is Capability IR.

Just as LLVM standardized compiler infrastructure and Kubernetes standardized application orchestration, I believe there is an opportunity to standardize Capability Verification.

The long-term goal isn't another security product.

It's a new layer of computing where every piece of software can answer a simple question before it ever runs:

"What am I capable of doing, and can I prove that I'm allowed to do it?"

15 views