Same architecture for SSH/Postgres - a note on the trade-off

[Walex4]

I’ve been following your posts on credential isolation for local agents - the daemon over a Unix socket so the agent never holds AWS credentials. I’ve spent the last few weeks building a parallel architecture for SSH and Postgres and independently arrived at the same two challenges you describe: credentials that can be exfiltrated, and the difficulty of predicting the permissions an agent will require.

• https://engseclabs.com/blog/agent-credential-isolation/
• https://engseclabs.com/blog/iam-agent-proxy/

My approach diverges in one place. Rather than brokering credentials, the broker exposes typed operations and performs them itself, so the credential never leaves the broker. That removes the “permission guessing” problem for the surfaces it supports - grants are over operations rather than IAM actions - but it requires a schema per operation, so it doesn’t generalize the way your credential broker does. Your system spans AWS; mine spans three protocols and must be extended manually.

I’m genuinely unsure whether that trade is correct, and you’re one of the few people with enough context to evaluate it. Design doc: https://github.com/Walex4/taper/blob/main/DESIGN.md - the prior‑art section is explicit that the token construction is Biscuit’s and the semantics trace back to SPKI. I’d value your critique more than agreement.

Best,
wale

[Walex4]

[Walex4]

Small update in case you look at this: I ran the install from a clean Ubuntu 24.04 this morning and found demo.py was broken on a fresh clone — every operation in sections 3, 4 and 5 returned a proof-of-possession failure, including the section that exists to show an allow. The captions were still describing the old behaviour. Fixed, along with the quickstart, which couldn't work on any PEP 668 distro.

Mentioning it because it's the same failure mode the repo is about: output that was plausible line by line and false as a whole, in the one file everyone runs first. There are now tests that assert on the demo's actual output rather than its exit code.

[michaelthomasletts]

Hi, Wale —

Thanks for reaching out.

To clarify, the blog posts you linked were written by Alex Smolen. Alex used elhaz as a dependency, but he did not author it.

Second, elhaz is fundamentally an AWS temporary security credential broker that takes a different approach from tools like aws-vault as outlined in the official docs. Consumers may be agents, but they could also be shells, scripts, SDKs, AWS profiles, or local developer workflows. In other words, elhaz is not primarily an agent-credential isolation system; it is designed for local AWS access using patterns native to AWS tooling. Agent-credential isolation was an anticipated use-case for elhaz, but it is an incidental consequence of the tool's design, to be completely honest.

With that major distinction in mind, my high-level reaction is that the trade you noted is plausible, but only under fairly narrow conditions:

1. The typed operation surface has to cover real workflows without eventually degenerating into raw_exec, arbitrary SQL, or broad HTTP forwarding.
2. The broker must not be the only meaningful boundary. Your Layer 2 point seems essential: sshd, Postgres, filesystem permissions, RLS, force-command shims, etc. still need to hold if the broker misclassifies or overpermits.
3. The operational burden is much higher than in a credential broker. Each supported protocol needs its own careful semantics, and each new operation is effectively security-sensitive product work. That's a lot.
4. The main failure mode I would watch for is policy pressure: if normal use keeps forcing grants toward broad wildcards, the typed-operation model may be telling you that the abstraction is too narrow for the job.

So I would frame Taper less like “the same architecture generalized beyond AWS” and more like “a different point in the design space”: narrower, potentially stronger for supported operations, but less general and with a larger per-protocol trusted surface.

I can offer that as a high-level reaction, but I can’t realistically give Taper a full design or security review in this discussion thread. For that, I’d suggest focusing reviewers specifically on the adapter semantics, target-side enforcement, and the falsification criteria you listed near the end of the design doc. Those seem more important than the token construction itself, especially since your own prior-art section already treats that part as mostly established.

Discussions on this repository are for matters concerning elhaz, not for requests to review other projects. Accordingly, I'll be closing this discussion.

[Walex4]

Thanks... and noted on Smolen. I'd conflated the blog posts with elhaz's authorship; that was my error, apologies for the mix-up.

Your reframing is fair. "A different point in the design space" is more accurate than "the same architecture generalized," and the larger per-protocol trusted surface is the honest cost of it.

Point 4 is the one I'm taking away - if real use keeps pushing grants toward wildcards, that falsifies the typed-operation premise, and it's measurable rather than a matter of opinion. Adding it to the falsification criteria. Appreciate the time.