Credential Logs Are Not Enough to Prove Authority: Five Fields to Check
Your agent log can show which token was used and which tool ran. It cannot show who approved that specific change, what limit it drew on, or whether that permission still stands. Five dimensions to hold your log against, each with a formal precedent written for somebody else.
A credential log records the call. An action receipt has to record the authority behind it.
An agent changed a production record last Tuesday. On Thursday somebody asks who approved it.
You can produce the token, the tool call, the arguments, the timestamp, the session. None of that answers the question. The log is doing exactly what it was designed to do, which is the problem.
This article proposes that an agent action audit log, the record this piece calls an action receipt, needs five dimensions: who authorized the action as distinct from who performed it, the bounded permission and limit it drew on, what was attempted, what actually changed, and whether that authority still stands. Each already has a formal precedent, written down for somebody else.
Kontext, a credential broker for coding agents, publishes what it captures on every tool call: "what the agent tried to do, what happened, whether it was allowed, and who did it." [1] One vendor's design choice, not an industry norm. Attempt and outcome are there. "Whether it was allowed" is an allow-or-deny observation, not the bounded permission drawn on. "Who did it" is the actor, not the authorizing principal. That list does not answer whether that authority still stands.
The interesting part is not that one list is short, but that for the authority questions there is no agreed vocabulary to point at.
A credential log answers "which key." It is not enough to answer "by what authority."
A credential log, the kind vendors now market as an AI agent audit trail, establishes which credential was used and which call was made. It does not establish who authorized that specific action, what bounded permission it drew on, or whether that authority still stands. Insufficient, not invalid.
The OpenTelemetry GenAI attribute registry, as enumerated on 2 August 2026, defines gen_ai.tool.call.arguments and gen_ai.tool.call.result. [2] Attempt and outcome have names. Read down that registry and no attribute records an authorizing party, an approval decision, a permission scope, a spend budget, or a revocation.
The custody camp sees the same seam and names it differently: "The problem isn't just secret sprawl. It's that there's no lineage of access." [1] A real advance, and the wrong axis for Thursday's question: lineage tracks the key, authority tracks the decision. Once agents hold persistent access to the systems a company runs on, the volume of actions needing explanation outgrows memory.
You cannot log an attribute that has no name. So whose job was it to name one?
The spec agents authorize through does not define the record
I read the Model Context Protocol authorization specification, revision 2025-06-18, end to end. [3]
It is dense with normative requirements, and they all point one way. Servers MUST implement RFC 9728 protected resource metadata, clients MUST implement RFC 8707 resource indicators, and servers MUST NOT pass through client tokens.
Checked against the full text of that revision, no requirement of any normative strength covers MCP audit logging: recording what was done with the token, who authorized it, or what changed. Not a MUST, not a SHOULD. A finding about one revision of one document, and the date is there so you can check me.
Not an accusation. The specification states its scope in the first line: it defines the authorization flow for HTTP-based transports, and authorization is OPTIONAL for MCP implementations at all. It did its job. In the sources reviewed here, the record falls between documents, though its parts exist, filed under other people's problems.
Five dimensions, five formal precedents, and no reviewed source that holds the row
Read it as a mapping. No row claims its precedent defines the receipt field.
| Proposed receipt dimension | Formal precedent | What that precedent establishes |
|---|---|---|
| 1. Authorizing principal, kept apart from the actor | RFC 8693 §1.1, §4.1, §4.4 (IETF standards-track, 2020) [4] | Delegation kept distinct from impersonation; act actor chains, nested for prior actors; may_act, permission to act for another. Gives the actor chain, not the authorizer. |
| 2. Fine-grained scope, plus an application-specific limit | RFC 9396 §1, §2.2 (IETF standards-track, 2023) [5] | authorization_details, a JSON structure for "fine-grained authorization requirements." No budget field, so limit encoding stays application-specific. |
| 3. Request parameters, the attempt | AWS CloudTrail record contents, format version 1.11 [6] | requestParameters, "the parameters, if any, that were sent with the request." A vendor record format, not a standards-body document. |
| 4. Event outcome and response | CloudTrail v1.11 [6]; NIST SP 800-53 Rev. 5, AU-3 [7] | responseElements for "actions that make changes," null for readOnly APIs. AU-3 requires an audit record to establish the event outcome. |
| 5. Invalidation and revision relations | W3C PROV-DM (W3C Recommendation, 2013) [8] | wasInvalidatedBy, "the start of the destruction, cessation, or expiry of an existing entity by an activity"; wasRevisionOf, a revised version of an original. General provenance, not agent authority. |
Each dimension has a formal precedent. No single document holds the row.
Two of these get misread. The authorizing principal is not the actor: RFC 8693 drew that line in 2020, where delegation leaves "principal A still has its own identity separate from B" while impersonation makes A "indistinguishable from B in that context." [4] Nested act claims give the actor sequence; recording the authorizer stays the receipt's job.
And scope is not the limit inside it. RFC 9396 explains why scope was not enough: it "is not sufficient to specify fine-grained authorization requirements, such as 'please let me transfer an amount of 45 Euros to Merchant A.'" [5] Scope alone cannot express a permission with an amount, and how you encode the cap is your design choice.
Once, plainly: this five-dimension receipt is an editorial framework proposed here, not a specification. No source reviewed here ratifies the row. What exists is five precedents written for five different readers, as far apart as 2013 and 2025. DCP, one current permission product, packs the same concepts into one marketing sentence, with nothing underneath it another system could read: scopes, approval "from Telegram or App," "daily budgets, logs, and instant revoke." [9]
A framework is a claim until something has been run through it.
Run it against five actions and see which dimension takes the weight
So run all five dimensions against five classes of action, and name the one hardest to fill in each. If a dimension is never the hard one, it does not belong.
One distinction is settled elsewhere: the CloudTrail record format makes readOnly a boolean on every event, and responseElements null for read-only APIs. [6]
The five classes below are original generic examples, not observed cases.
- A read, an agent querying a customer record. Hardest is scope: which records, which fields, for how long. Outcome is near-empty by design, and over-recording here is the privacy risk NIST raises below.
- A prepared draft, a pull request or a proposed budget move. Hardest is outcome, deliberately null: the receipt must separate "nothing happened yet" from "nothing happened."
- An external write into somebody else's system. Hardest is attempt and outcome together, since outcome is the only evidence the change landed.
- A limit-consuming action, spending against a cap. Hardest is the limit half of scope: which cap was drawn against, and what remained. The 45-Euro line was arguing about this class.
- A delegated sub-action, one agent handing work to another. Hardest is the authorizing principal: two or more actors, one authorizer. [4]
Five action classes, the same five dimensions. Each class exposes a hard dimension or pair, and authority status stays open in all five.
Four take a turn as the hard one. The fifth never does, and that is the finding: at write time, "does this authority still stand" is always yes as far as anyone knows. It is the only dimension whose value can change after the record closes, and the only one none of the vocabularies above carries. Adding attributes to a span is not designing a record.
Here the dimensions agree. The cases worth arguing about are the ones where they contradict.
The interesting cases are the ones where the dimensions disagree
Take "whether it was allowed." In one vendor's self-reported implementation that is an observation, not an enforced gate: "the infrastructure for allow/deny decisions on every tool call is already wired, we just need to close the loop so tool calls can also be rejected." [1] Recorded-as-allowed and actually-gated look identical in a log line.
Second: an approval nobody outside the vendor can inspect. Anthropic's auto mode for Claude Code gates each action before execution, and TechCrunch reported on 24 March 2026 that "Anthropic hasn't detailed the specific criteria its safety layer uses to distinguish safe actions from risky ones." [10] A gate you cannot inspect is not a substitute for a record, and it is where the operator's job is catching what a confident system got wrong.
Third, quieter. Past CloudTrail's 1 MB event limit, the documented truncation order drops responseElements before requestParameters, with errorMessage surviving longest. [6] Reading that as a ranking of what matters most is my inference, not an AWS statement. Read it that way anyway: it puts the attempt above the outcome, and for an agent I doubt that is right.
One disagreement is worse, because none of the surveyed vocabularies can represent it.
Revoking a token does not tell you what was done under it
RFC 7009 is short and unambiguous. "The invalidation takes place immediately, and the token cannot be used again after the revocation." [11]
Under RFC 7009 the invalidation is immediate and applies going forward. The specification does not address access that already completed.
The rest keeps that shape: future token validity, nothing about access that already completed, no way to determine prior use. The consequence is narrow, and it holds: nothing in the token layer marks a completed action as taken under authority later withdrawn, and none of the vocabularies in the table above carries that relation for agent actions. Other systems can annotate their own records, and some do. If "was this authority later revoked or superseded?" is to be answerable, this framework recommends the receipt carry it.
The closest existing vocabulary is thirteen years old: W3C PROV standardized wasInvalidatedBy and wasRevisionOf in 2013 as general provenance relations. [8] Right shape, different purpose.
Operators already run this pattern. Agimon's portfolio ledger is append-only: you supersede a decision instead of editing it, so the old call and its evidence stay beside the new one. That is what a decision record needs when more than one reader has to trust it.
The objections, including the two that land
Start with the most legitimate, from the publication that specifies audit content. NIST SP 800-53 Rev. 5's AU-3 discussion warns that audit records "can reveal information about individuals that may give rise to privacy risks," singling out trails that record inputs. [7] My answer, a recommendation rather than a NIST prescription: record the authority, not the secret. The permission identifier, not the credential. The approval, not the reasoning behind it. Model output is not evidence, and storing it is the hazard AU-3 names.
Then custody, the strongest opposing view: underneath the pushback on server-side custody ("That probably makes this thing DOA for most people") sits the position that where the secret lives is the real problem. [1] Largely correct, and a brokered short-lived credential shrinks blast radius. But custody bounds the damage while the receipt explains the event: a perfectly brokered credential still leaves a log that cannot say who approved the action.
Cost is the practical objection: agents move fast, receipts are bureaucracy. But somebody has worked out what a per-action structured record contains. CloudTrail's official record format, version 1.11, specifies a readOnly boolean, separate requestParameters and responseElements, a 1 MB event size limit, and a documented order for what gets dropped first. [6] An operable design, not a thought experiment.
That objection lands halfway. The gap is assembly and vocabulary; the implementation does not need to invent these five dimensions. Somebody still has to build them: name the fields, thread the authorizing principal through the call path so it exists at write time, decide the limit encoding, store and keep the records. Real engineering, with real storage and retention cost.
One more, flagged as mine. AU-3 requires the identity of individuals, subjects, or entities associated with an event. [7] It does not require the authorizing party as distinct from the performing one. For a human clicking a button those collapse; for a delegated agent they do not. My inference, not NIST's.
If the argument holds up for you, send it to whoever owns your agents' write access.
Take the five checks to one action an agent ran for you this week, and find the one your agent action audit log cannot answer.
- Who authorized it, recorded separately from who ran it?
- What bounded permission and limit did it draw on?
- What was attempted?
- What actually changed?
- Does that authority still stand?
Be clear about what this is not. The sources reviewed here establish no adopted standard, certification, ratified schema, or measured reduction in incidents, and Hacker News points are attention rather than adoption.
The parts were written down years ago by people solving five different problems, and not one of them was writing for you. Assembling the row is the first practical step.
References
- "Show HN: Kontext CLI, credential broker for AI coding agents in Go." Hacker News. https://news.ycombinator.com/item?id=47765374. Accessed 2026-08-02.
- OpenTelemetry. "Gen AI attributes" (semantic conventions registry). https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/ . Accessed 2026-08-02.
- Model Context Protocol. "Authorization," specification revision 2025-06-18. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization . Accessed 2026-08-02.
- Jones, M., Nadalin, A., Campbell, B., Bradley, J., Mortimore, C. "RFC 8693: OAuth 2.0 Token Exchange." IETF, January 2020. https://www.rfc-editor.org/rfc/rfc8693.html. Accessed 2026-08-02.
- Lodderstedt, T., Richer, J., Campbell, B. "RFC 9396: OAuth 2.0 Rich Authorization Requests." IETF, May 2023. https://www.rfc-editor.org/rfc/rfc9396.html. Accessed 2026-08-02.
- Amazon Web Services. "CloudTrail record contents for management, data, and network activity events," record format version 1.11. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html . Accessed 2026-08-02.
- National Institute of Standards and Technology. "AU-3: Content of Audit Records," SP 800-53 Rev. 5. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final. Accessed 2026-08-02.
- Moreau, L., Missier, P. (eds). "PROV-DM: The PROV Data Model." W3C Recommendation, 30 April 2013. https://www.w3.org/TR/prov-dm/. Accessed 2026-08-02.
- Product Hunt. "DCP: give your AI agents encrypted permission and keys." https://www.producthunt.com/products/dcp. Accessed 2026-08-02.
- Bellan, Rebecca. "Anthropic hands Claude Code more control, but keeps it on a leash." TechCrunch. https://techcrunch.com/2026/03/24/anthropic-hands-claude-code-more-control-but-keeps-it-on-a-leash/ . Published 2026-03-24. Accessed 2026-08-02.
- Lodderstedt, T., Dronia, S., Scurtescu, M. "RFC 7009: OAuth 2.0 Token Revocation." IETF, August 2013. https://www.rfc-editor.org/rfc/rfc7009.html. Accessed 2026-08-02.