Show HN: Jo – AI-native language to catch prompt injection at compile-time(github.com)
github.com
Show HN: Jo – AI-native language to catch prompt injection at compile-time
https://github.com/typescope/jo
14 comments
Nicely done. This isn't a criticism, but i wonder if a well designed system needs prompt injection guards at all. Provided all security happens outside of the models and models only have access to data and resources that are scoped to the user. I guess model security is exactly the same as employee security, least privilege, sand boxes, etc
Injection is runtime data, so 'compile-time' overstates it. A type system can taint-track — mark untrusted input, block it from a privileged sink. Valuable, but that's enforcement, not detection.
That is true -- the title does not precisely state what Jo is. It bounds the dangers that prompt injection can cause to arbitrary granularity.
I (the author of Jo) built Jo because I kept asking myself: can we solve the sandboxing problem at the language level — one that's actually aware of business logic?
Runtime sandboxes block syscalls, but they can't enforce "only this user's rows" or "only this API endpoint." That's application-level precision, and no sandbox can see it.
Jo's answer is to make capabilities typed parameters. If you haven't received one, you can't use it — the compiler proves this through the whole call graph, at whatever granularity your interfaces define.
This allows programmers to create bounds of arbitrary granularity that can contain the damages that can be caused by prompt injection.
I (the author of Jo) built Jo because I kept asking myself: can we solve the sandboxing problem at the language level — one that's actually aware of business logic?
Runtime sandboxes block syscalls, but they can't enforce "only this user's rows" or "only this API endpoint." That's application-level precision, and no sandbox can see it.
Jo's answer is to make capabilities typed parameters. If you haven't received one, you can't use it — the compiler proves this through the whole call graph, at whatever granularity your interfaces define.
This allows programmers to create bounds of arbitrary granularity that can contain the damages that can be caused by prompt injection.
I like that this feels driven by a coherent design philosophy. and the emphasis on AI security is very timely as AI-generated code becomes more common
I am building an AI agent using Jo. I believe Jo has great potentials in this field with its capability-based security features. Great work!
Congratulations! It's great to see the Jo project steadily maturing.
the capabilities design is really cool, however to protect against prompt injection to unauthorized db access, couldn't we just use api only agent or db features like pg RLS
yeah, not really, actually. in my opinion, they may work, but with tradeoffs
api wrappers are safe, but they kill flexibility of AI agent and will have massive maintenance bottleneck
db-level security is a great runtime boundary, but it is completely disconnected from application business logic
api wrappers are safe, but they kill flexibility of AI agent and will have massive maintenance bottleneck
db-level security is a great runtime boundary, but it is completely disconnected from application business logic
[deleted]
[deleted]
[deleted]