mcnamtm1

"Agents started calling tools nobody remembered wiring up"

This is very familiar to me. I have seen this problem before. Because AI is often a network of microservices and follow service mesh patterns, there is an inherent ability for agent workloads to reach other agent workloads even if they weren't designed for that. To me, that is an 'authorization' problem and traditional solutions focus on policies to control authorization. But an authz policy approach is avoided because it involves a central server, additional latency, and is a single point of failure.

I found a different approach that restricts the authorization of agent interconnections to a pre-defined topology and has strict access controls per agent during runtime use dynamic access credentials unique to the agents in the topology. There is no central server.

And the dynamic access credentials guarantee the control and security of the data flows over the authorized AI topology during runtime.

I think about securing AI systems a lot. And I am amazed that people expect conventional API security to protect AI systems when these same solutions are failing tremendously for every other kind of API. In my opinion, AI is a leap-ahead technology that needs a leap-ahead security approach rather than the conventional API security methods.

Happy to discuss further

I started coding in the late 70's (not 1908). I suppose I will take the "older folk" label as a compliment :-) I coded with Fortran and "wrote" software on punch cards that had to be compiled by a machine that read the cards and they had to be kept in order (line by line). The code went into a large mainframe computer and was scheduled with other jobs. Sometimes you would wait for hours to get large printed sheets of output. Then review it and start over again with fixes and patches.

Fortran was the 'scientific' language. People in the business schools learned Cobol.

We tackled a similar problem for K8s workloads—verifying automated service identity trust without static credentials.

A few thoughts on your approach:

*Persistent identity + rotation:* The tension between "persistent" (provable history) and "rotating" (security) is real. Persistent identity often means persistent credentials, and we know these can't be trusted to remain secure for very long. We solved this with identity credentials that rotate daily but build a verifiable chain of trust in the workload (i.e. Zero Trust for workloads). Each new identity is cryptographically linked to the previous one.

Have you considered rotation schedules for MoltID agent identities?

*PoW for Sybil resistance:* Smart for initial onboarding. Curious: Do you distinguish between "initial trust establishment" (high friction, PoW) and "ongoing verification" (low friction, fast crypto proof)? Or does every verification require PoW?

*JWT tokens:* We went a different route — no tokens over the wire. Both parties generate identical credentials locally (synchronized algorithms, no key exchange). This eliminates token theft as an attack vector.

*Two Rotating Credentials* We went for a pre-shared algorithm for the secret/key, and a third-party identity trust verification model. Separation of two credential needed to gain access among agents. worth considering for direct agent-to-agent communication?

*Question:* How are you handling trust bootstrapping? In OAuth, there's a trusted IdP. For autonomous agents with no human, what's the root of trust?

Agree that work—agent identity will be huge as agentic AI scales.

(Disclosure: We're building Lane7 for K8s app network topologies. Not a pure agentic use case, but an overlapping problem.)

Very interesting use of Firecracker for agent isolation.

How do you handle network identity for the agents themselves? Are you using something like mTLS/SPIFFE to identify the workload inside the VM, or is it purely network-policy based at the host level? Can you explain the "runtime enforcement" and the "enforcing tool proxy?

Good question. To clarify: the app still has its own internal auth logic — we're not bypassing that.

The encrypted lane handles connection isolation (who can reach the app), while the app still handles identity (who the user is).

For agent-to-app communication specifically, the pattern we use: 1. Agent passes a short-lived token in the request payload (not URL) 2. App validates the token against its local auth store 3. The encrypted lane ensures no one else can intercept/replay that token

Let me clarify. I am not suggesting disabling authentication inside the app. I am suggesting a solution is to layer the network isolation + application auth. The secure application layer channel just removes the OAuth redirect dance for machine-to-machine flows.

For human access, you'd still need SSO. But once the human is authenticated, the services authenticate to one another (machine-to-machine) also at the application layer (not layers 3/4).

Does that make sense for your use case, or are you looking for something that works with human SSO flows too?

We have a real setup that treats this challenge as a network isolation problem instead of an auth problem. Have you considered that approach?

Meaning: instead of trying to authenticate to the preview app, make the preview app only reachable via an encrypted application-layer channel. The "authentication" becomes having the encryption key to that channel.

For AI agents, this could simplify things:

Agent generates an encryption key when spinning up preview Preview app runs in isolated network (e.g., behind a customized Envoy proxy doing application-layer encryption without PKI/TLS) Agent communicates with preview over the secure channel No OAuth redirect URLs needed at all

The pattern we've been using is basically "encrypted lanes" between services - each preview gets its own lane(s), fully ephemeral. When the preview dies, the lane disappears.

Main downside is this doesn't help if you need humans to access the previews with their SSO credentials. But for agent-to-preview-app workflows, it's been cleaner than fighting OAuth's assumptions.

Curious if you've explored this direction or if there are constraints that make network isolation insufficient?

I think it matters how you define 'end-to-end'. Where are the endpoints? In a SaaS platform, WhatsApp could claim your device and its ingress server are the endpoints. With that definition, they can use TLS and claim E2EE.

But some people would expect the two endpoints to be their device and their human counterpart's device. Mobile app to mobile app and encrypted across all servers.

I am in Camp A. I verify AI-generated content closely. I am usually using AI to improve content that I have provided. Because I am knowledgeable about the information and topic, I can quickly recognize when AI is wrong or stupid.

I find a lot of errors and would never recommend Camp B as a smart way to use AI. It may seem efficient, but knowledgeably readers or listeners will lose trust in you.

I think fail-secure is the right strategy for agentic AI, especially if the actions taken are irreversible or control something significant. The generative AI systems make a lot of errors.

There is so much risk when human supervision is not present.