The problem is structural, not behavioral. Agents that behave correctly in development still reach further than intended in production — because nothing at the runtime level prevents it. Prompt guardrails are not a boundary. Application-level checks are not a boundary. kura is.
// the runtime boundary problem
An agent that can reach anything will eventually reach the wrong thing. The question isn't whether your agent is well-behaved — it's whether your infrastructure assumes it isn't.
boundary risk
Unintended Infrastructure Reach
Agents dynamically invoke tools, APIs, and services at runtime. Without a hard boundary, a misconfigured tool call or unexpected execution path can reach internal systems the agent was never meant to touch.
boundary risk
Credential Exposure at Runtime
Service tokens and credentials passed into the execution context are accessible to the agent. Under compromise or unexpected behavior, that blast radius extends to every system those credentials can reach.
boundary risk
No Hard Egress Boundary
Container isolation governs processes, not agent behavior. An agent with network access can establish outbound connections, exfiltrate context, or invoke external endpoints — unless something at the runtime layer explicitly prevents it.
boundary risk
Unpredictable Tool Invocation
Tool surfaces expand as agents become more capable. Dynamic invocation at runtime means the set of reachable endpoints isn't fully known at deploy time — making static policy definitions insufficient on their own.
// the kura approach
Enforcement at the Runtime Boundary
kura wraps your agent in a controlled execution environment before anything executes. Network egress, tool invocation, credential access, and service calls all pass through the kura boundary — where explicit allow policies govern what proceeds.
- Deny-by-default execution posture
- Proxy-mediated tool and API invocation
- Credential brokering outside the agent context
- Hard network egress boundary at runtime
No Agent Code Changes Required
kura wraps existing agents without modification. Drop it around your LangGraph workflow, your custom Python agent, or any framework-based implementation. The runtime boundary is infrastructure — not instrumentation.
Full Execution Traceability
Every tool call, network request, and policy decision is logged with full context. Know exactly what your agent attempted, what was allowed, and what was blocked — at every step of every execution path.
Scales with your team: kura is the developer entry point. As your deployment grows, AgentVisor™ and PolicyEngine™ extend this boundary model to enterprise-scale governance — without replacing what kura already enforces.
Built around your workflow: developers keep their existing tools, frameworks, and agent code. kura changes the execution boundary — not how software is built.
// guarantees
// kura enforces these at the runtime layer — not the application layer
Hard boundaries. Explicit allow lists. Nothing your agent does at runtime can reach outside what you declared.
Deny-by-default execution posture
Proxy-mediated tool invocation
Hard network egress boundary
Credential brokering at proxy layer
Full call-level audit logging
Replayable execution traces
No agent code modification required
Kubernetes-native deployment
Framework-agnostic wrapping
// get started
01
Wrap Your Agent
Drop kura around your existing agent. No code changes to your agent logic. Deploys as a Kubernetes-native runtime wrapper alongside your existing stack.
kura wrap ./my-agent --policy default.deny
02
Define Your Boundary
Declare explicit allow policies across tools, endpoints, credentials, and services. Everything not declared is denied. Start minimal and expand with confidence.
kura policy allow --tool search --tool db:read
03
Run with Confidence
Your agent executes inside the kura boundary. Every call is logged, every policy decision is traceable, and nothing outside the declared scope can be reached.
kura run --trace --audit-log ./run.log
// how it works
Agent Codeyour logic, unchanged
→
kura Runtimeruntime boundary
→
Policy Evaluationallow / deny / log
→
Proxy Layertool · network · credential
→
Authorized Callonly what's declared
✕
Everything Elseblocked at boundary
0
Default Network Access
deny-by-default posture
deny-by-default posture
100%
Call Auditability
every invocation logged
every invocation logged
0
Agent Code Changes
wrap, don't rewrite
wrap, don't rewrite
∞
Execution Paths Covered
policy governs all of them
policy governs all of them
// with vs. without kura
| Risk Area | Without kura | With kura |
|---|---|---|
| Network Egress | Open by default — depends on container policy | Deny-by-default — explicit allow required at runtime boundary |
| Tool Invocation | Application-managed — no runtime enforcement | Proxy-mediated — every call passes through the runtime boundary |
| Credential Access | Available inside execution context | Brokered externally — never exposed to the agent directly |
| Infrastructure Reach | Bounded only by what credentials can access | Bounded by explicit policy — nothing else is reachable |
| Execution Visibility | Fragmented logs — no unified execution record | Full trace per execution — every call logged with decision context |
// why kura
Built for the Way Developers Actually Work
kura doesn't require a governance team, a policy language certification, or a platform migration. Wrap your agent, declare your boundary, run. It fits into your existing stack without ceremony — and gives you a hard runtime boundary from the first deployment.
Containment That Can't Be Reasoned Around
Prompt-level guardrails can be bypassed. Application checks can be skipped. kura's enforcement is structural — applied at the runtime and proxy layer where the agent has no visibility and no ability to work around it. The boundary is real.
The Audit Trail You'll Want When Things Go Wrong
Every execution path is logged. Every tool call, every policy decision, every blocked attempt. When something unexpected happens — and it will — kura gives you a deterministic reconstruction of exactly what your agent did and exactly what it was prevented from doing.
The On-Ramp to Enterprise-Scale Governance
kura is where you start. When your deployment grows — more agents, more teams, more infrastructure scope — AgentVisor™ and PolicyEngine™ extend kura's runtime boundary model to full enterprise governance. No rearchitecting. No throwing away what you already have.
// built by Manetu's engineering team — kura is our contribution to the developer community from the engineers at Manetu. It reflects the practical runtime-boundary patterns we built while deploying autonomous agents in production environments. We built it because we needed it. We're sharing it because you probably do too.
Talk to us about kura in your environment
// walk through your agent architecture, your infrastructure scope, and your boundary requirements. we'll show you how kura fits.