The Jo Language
Compile-time security for AI-generated code
AI generated code can exceed their permissions under prompt injection. Jo's type system enforces capability boundaries before the code runs — not after.
Risks of AI generated code
Without auditing and reviewing, running AI generated code can trigger malicious actions and cause serious security issues.
Prompt Injection
Adversarial inputs redirect model behavior, pushing generated code outside its intended scope and permissions.
Privilege Escalation
Generated code attempts actions outside its granted authority, accessing other users' data or elevated APIs.
Data Exfiltration
Sensitive data is sent to unauthorized destinations that a runtime sandbox cannot intercept or prevent.
Flexibility vs. security: a false choice
MCP or code generation?
MCP tools are inflexible and token-expensive. LLM code generation is powerful and composable, but there's no security primitive to bound what the generated code can do.
Securing LLM generated code
Probabilistic methods are not reliable. Sandboxing can block syscalls but cannot enforce business-logic rules. REST API + sandboxing incurs development and maintenance overhead.
Language-based security
Language-based security uses type systems and static analysis to enforce security policies at compile time — lightweight, precise, and expressive for business-logic rules without runtime overhead.
Compile-time confinement is not yet a standard practice. Jo establishes it while the ecosystem is still consolidating around sandboxing approaches.
What Jo Offers
Compile-time security
Security is enforced by the type system at compile time, not runtime policies or prompt rules. Violations are type errors, not incidents.
One Universal Tool
A single tool that runs Jo code gives the LLM all the power it needs — making APIs programmable rather than exposing a fixed menu of MCP tools.
Just an API
Integrate via a plain function call — no MCP servers, no infrastructure to operate. Jo compiles to Python and Ruby, so your existing stack stays.
Reduced token consumption
LLMs generate code to process and filter data based on the capability interfaces and return only what the LLM needs, reducing token and context window consumption.
Fine-grained authority
Agent developers can define arbitrarily fine-grained authorities specific to their business security context. E.g, restricting read-only access to current user's data.
Clear Security Boundary
The capability contract is explicit and statically verifiable. Auditors see exactly what AI code can and cannot do, localizing auditing efforts to API implementations.
How It Works
Define capability interface
Declare exactly which operations generated code may call. These interfaces are compiled without FFI support.
Implement capability interface
Implement capability contract that attenuates authority. E.g, full database access becomes user-scoped, read-only access.
Compile and verify statically
The Jo compiler verifies that generated code uses only declared capabilities. Violations are type errors.
Execute with enforced boundaries
Run only code that satisfies the declared security contract. No runtime sandbox required for this guarantee.
Declares the typed contract. OrdersApi defines what the AI code can call.
defer def aiMain specifies the function signature the LLM must implement — checked by the compiler.
The receives clause restricts that the AI program may only use the capability ordersApi passed to it — no network, file system, nor even stdout.
The compiler proves this at build time. No runtime sandbox is required for this guarantee.
Open Source
Open source foundation
Jo language, compiler, docs, and case studies are open source, so teams can evaluate the approach directly and build on a transparent foundation.
View TypeScope on GitHubEnterprise
Enterprise assurance
TypeScope provides architecture guidance, hardening support, and security review artifacts for production deployments.
Contact Us