← Back to blog
· By

Secure Runtime Binding: Proving LLM Agent Identity at Execution

Learn how runtime binding uses X.509 certificates to verify agent identity, enforce scope limits, and prevent privilege escalation in autonomous systems.

Proving LLM Agent Identity at Execution
Table of Contents

The Problem: Unbound Execution

Imagine a trading bot running on a server. It has an API key in memory. A vulnerability is discovered—an attacker gains code execution on the server.

Without runtime binding: attacker gains shell access, finds API key in memory, runs unauthorized trade.

With runtime binding: agent attempts action, signing service checks identity, request is refused from unauthorized IP/region.

The difference: the agent's identity is cryptographically bound to the runtime environment, not just stored in an API key.

How Runtime Binding Works

Step 1: Bind Certificate at Startup

When the agent launches, it gets an X.509 certificate from Kakunin with agent name, public key, and scope policy.

Step 2: Sign Every Action

Before executing any significant action, the agent signs it with its certificate, then submits with proof of identity.

Step 3: Verify Signature at Receiver

The exchange verifies certificate validity, checks revocation, verifies signature, extracts scope, and enforces limits.

Real-World Example: MiCA Compliance

A crypto exchange in the EU deploys a trading bot that executes algorithmic trades autonomously, stays within regulatory limits, and provides audit trails.

Bot trades within scope, agent submits with certificate and signature, exchange verifies and logs. At audit, regulator verifies cryptographic proof.

Three Layers of Protection

Layer 1: OS-Level Scope Enforcement — Agent process labeled with policy, OS enforces file access limits.

Layer 2: Network-Level Identity (mTLS) — Agent presents certificate to API, mutual authentication established.

Layer 3: Application-Level Signature Verification — Every request includes signature, application verifies and enforces scope.

Defense-in-depth: attacker needs to compromise all three layers.

Why This Matters for LLMs

Prompt Injection: Malicious input tries to convince bot to ignore scope limits. Runtime binding says "No, your certificate says max €25k."

Memory Corruption: Attacker corrupts agent state to execute oversized trade. Signing service enforces scope independently. Trade refused.

Code Injection: Injected code tries to bypass checks but still needs kakunin.sign(). Service enforces scope. Injection contained.

Ready to bind your agent to cryptographic identity? Add hero image in Sanity Studio, then publish.

All articles →
Read more from the blog
Documentation →
API reference and guides