[WIMSE] Re: Review of draft-klrc-aiagent-auth-03

[Christian — Keel <[e-mail]>]

Hey Kunal, thanks for this....

It's a genuinely thoughtful review, and I think points #1 and #5 get right to the heart of it.

Let me try to build on both.



On #5: I'd really like to see that distinction between posture at issuance and behavior at request time called out explicitly in the threat model because it's doing a lot of quiet work. Authentication tells you who or what the agent is at the moment it's issued a credential, and short credential lifetimes don't change that. What it doesn't tell you is whether the specific thing the agent is trying

to do right now is actually authorized. That's a hole. A compromised-but-attested agent, say one that's been prompt-injected, is holding a perfectly valid, fresh, unrevoked credential the whole time, and uses it to do something it shouldn't. Expiry won't catch that and revocation won't catch it because the credential was never the thing that got subverted.



The action was.



On #1: I'm with you on scoping Section 8 to credential exposure, and I think it ties straight back to #5. Short-lived credentials are great for the theft and exposure case. They just don't do much for an agent that's fully credentialed and compromised. That leftover case is what makes me want to treat per-action authorization as its own control, sitting alongside authentication and revocation instead of getting folded into credential lifecycle. In practice that can look like a pre-execution authorization decision that's cryptographicallly bound to the actual bytes of the request being authorized, and that you can verify after the fact. It's on top of the credential and revocation machinery the draft already has instead than replacing any of it.



So concretely: it might be worth having Section 14, and maybe the Section 8 and 11 language, name these two layers separately, since what mitigates one doesn't mitigate the other.



One disclosure while I'm here. I recently posted draft-munoz-wimse-authorization-evidence as a companion profile covering the audit-evidence side of Section 11, and I'd be glad to line up terminology wherever it helps.



Thanks again for getting into this.



Best,

Christian Munoz

Keel API, Inc.