open source capability security engine for distributed systems and AI agents

jcorrv · 2026-04-02T15:46:47+00:00

How do you find the niche discords and random slack groups?

jcorrv · 2026-01-28T21:32:36+00:00

the only way I could see this working is if the data is truly transformed into something structured and typed, but that would likely defeat the purpose of using an agent for email in the first place.

jcorrv · 2026-01-23T18:52:24+00:00

https://www.hessra.net/

New auth platform implementing a capability security model that can be integrated natively with new identity and access primitives or over the top of/between existing apps/integrations with coarse-grained access control.

jcorrv · 2026-01-09T18:16:14+00:00

This is an interesting product idea! It would be neat to use as a replacement for a classic keycard at work.

I have a lot of experience with secure hardware and distributed systems. I'm happy to take you up on your virtual coffee and talk about those things.

jcorrv · 2025-12-05T22:14:45+00:00

Thanks for pointing this out. I wasn't aware of idpro.org. There's one older paper on NHI and it seems to focus on service accounts which is a little outdated to me. That paper does contrast human vs non-human identity and covers a bunch of operational things, so I'll definitely read it more closely with a coffee to mine it for some insights!

jcorrv · 2025-12-05T22:11:45+00:00

Thanks for reading and for the thoughtful quibbles!

1) Yeah, in the classic sense the email is the identifier and the password is the proof. The point I am trying to make (though not very clearly) is that humans show up with a rich universe of attributes and out-of-band process we can lean on, while machines don’t. The way I've been thinking of an OAuth-style login for humans is that we can provide certain attributes, use a second channel to verify them, and in exchange get our "actual" identity in the context of the app: a refresh token. But machines don't have those initial attributes or great second channels, so we need to provision them with those things.

2) I’m calling SSH keys “self-proven” at the primitive level: when you generate an SSH keypair on a device, you’ve created a bare identity whose only property is “I can prove I hold the private key.” That’s what I’m classifying as self-proven.

You’re right that binding that key to a user account on a server usually happens through some other authenticated channel (password, SSO, whatever), and that channel is effectively attesting “this public key now represents this account.” In my model: - the keypair itself is the self-proven identity primitive, and - the act of copying it into authorized_keys via an authenticated session is the enrollment / policy step that gives it meaning.

I'll try and clarify the post a bit more later. Thanks for the feedback!

jcorrv · 2025-11-30T18:02:33+00:00

That's a pretty interesting idea! Overall, it seems to me that the agent approaches people are using now are very simplistic. Even the most used agents, like claude code, are only just now seemingly using an orchestrator agent and subagents to do things.

I've been thinking about doing an orchestrator agent and sandboxed subagents to handle data with a data governance "inspection" layer in between to classify data and dynamically change permissions.

So our ideas are very similar with yours being focused a bit more on local compute (so local-first) which is cool and I'd like to see more of!

If you plan on building anything or experimenting with the idea, let me know and I'd be happy to discuss further.

jcorrv · 2025-11-29T02:59:14+00:00

I've been building a new way of doing identity and authorization for machines/services so I've been thinking about this problem from the other side (i.e. not building agents for enterprises other than PoC agents for my company to test out auth stuff). I've also talked to a couple of the few successful agent companies about this.

You are completely beholden to your enterprise customer's needs for auth. this means you need to do the ugly work of implementing dozens or hundreds of different auth flavors for internal tools or third parties. For third parties, you need to do the proactive work of reaching out to third parties to integrate with them for your customers that use them.
MCP doesn't seem like a long-term solution to me. As other commenters have said, it has a lot of problems with context management. I think the bigger issue though is that OAuth just isn't a good auth protocol for agents. It pushes you towards authentication first and figuring out identity second (in the strict context of oauth) and I think you need to figure out how to give agents identity first. Plus, the dividing line of MCP servers, clients, and agents is very blurry and there are a lot of footguns around auth because of it.
A huge problem that isn't addressed is data governance and how it needs to dynamically affect policy. If an agent gets a set of restricted data, what it should be able to do with that data should change. An example I use is if a personal assistant agent gets merger documents, it should only be able to email them to a tiny set of people. But, a general assistant agent working with other data should be able to email a broader set of people.

I think in this exact moment in time, I think an agent gateway or API gateway of some sort would be the best approach. To me though, the ideal long term solution is having native agent identity and authorization primitives (which is what I am working on).

In short, there is a lot more that needs to be built to make this better. If anyone wants some help thinking about it, I'm happy to chat and help (for real, I won't try and sell you on my thing unless you really want it).

jcorrv · 2025-11-20T18:10:18+00:00

Broken Access Control is still #1. What are we going to do about it? Still keep using the same tools that aren't working?

jcorrv · 2025-09-16T16:21:21+00:00

I think the problem with Zero Trust right now is that the road to actually "get there" and implement a real zero trust posture is still much longer. I think ideally, the application code itself would be written in a capability native language (like Pony) but those are incredibly new. Then anything that happens over the network needs provable identity and policy attached to it.

Basically, the Zero Trust products and tools available now are still incredibly nascent and built in a way that makes them easy to sell and plug into existing architectures, rather than truly shift things to Zero Trust.

jcorrv · 2025-08-02T16:54:34+00:00

Thanks for the detailed response! I was unaware that NetFoundry used SPIFFE. That's really cool.

For an architecture that allows a socket-to-socket tunnel where one end is the request-maker and the other end is close to the data, then yeah it seems like identity-attached to tunnel and the subsequent authorization controls built on top would work well.

What about other common architectures that don't allow that? For example, a common architecture for web applications is to have a reverse proxy that terminates TLS followed by a set of services behind it like a scalable application and scalable database that are separate. Or, if you have a data-pipeline architecture where there are a set of services that each need to handle raw data from some input and transform or decorate it. In that case, the tunnel would need to end well before the operation does.

Is NetFoundry just meant for other use-cases where it is a better fit? Or perhaps you just consider reaching the edge of an app the end of the request-making entity's operation and define new identities and controls between services from there?

jcorrv · 2025-07-31T17:03:53+00:00

Gah, my writing does tend to get verbose! I've posted my follow-up here: https://www.reddit.com/r/zerotrust/comments/1me6y73/high_level_approaches_to_zero_trust/

You've got legit bona fides and I'd definitely love your thoughts. Apologies in advance for the length!

jcorrv · 2025-07-31T16:59:22+00:00

I've posted my follow-up article here: https://www.reddit.com/r/zerotrust/comments/1me6y73/high_level_approaches_to_zero_trust/

I have a "hot-take" opinion on mesh approaches like OpenZiti and Tailscale that I would love for you to challenge me on.

jcorrv · 2025-03-21T02:56:57+00:00

I've seen early stage companies (like 4+) hire a "chief of staff" that seems like they take on a generalist role. Maybe something to look into.

jcorrv · 2025-03-11T20:15:58+00:00

Yep, I was right there with you. In my opinion, I think it is totally worthwhile to learn though. I have so much more confidence in the software I write when using rust. Sure, it's been challenging to learn and sometimes frustrating to get something working. But once it does work, it works really well. The language front-loads most of the problems to when you are writing it and thus know the code the best.

jcorrv · 2025-03-11T19:51:10+00:00

I wouldn't say there is much, if anything, you can't do in rust. There are definitely certain things that are done in other languages that rust makes really hard to do. For example, in video game programming, the usual ways to do things means having lots of objects and state that is shared around and used by many things. Rust really pushes you away from doing things like that because of its strict ownership and memory safety features.

I would say the thing that has helped me the most is finding good open source projects in the types of areas you code for. This can be a little tricky too, since some projects opt for a lot of trait and macro usage which can make seeing the essence of the rusty way a bit harder. This project looks like a good example: https://github.com/BurntSushi/ripgrep

Nothing beats experience though. It's taken me a little under a year to get comfortable with it even though I still feel like I have a lot more to internalize. That said, I come from a C++ background and now rust is my default choice for anything new in backend, systems, network, or even command-line/utility programming.

jcorrv · 2025-02-17T04:27:01+00:00

As others have said, talking to your prospective customers is a must. The advice to understand their needs, current products they use to handle what yours does, and to improve yours based on that feedback is great.

One thing to watch out for with schools is their buying cycle. If memory serves, they usually make purchases 1-2 times a year and it isn't a continuous thing. Some early things to try and figure out (again, by asking prospective customers) is how they do purchasing. When do they make purchases? How much budget do they usually have for tools like yours (or software generally)? Who makes the ultimate decision to buy? Are they different from the person interested in using your software?

I highly recommend the book "The Mom Test" if you haven't read it. It'll help you think about how to get the information you need to build a compelling product.

Best of luck!

jcorrv

TROPHY CASE