Crumb: Forging the Digital Trail to Human Accountability in the Age of AI Agents

The advent of sophisticated Large Language Model (LLM) agents deployed in production environments presents a growing and unaddressed challenge to established accountability frameworks. These autonomous software entities, often operating under generic service accounts or shared API keys, perform critical tasks ranging from data record processing and file exports to initiating financial transactions. While traditional audit logs diligently record these actions, attributing them merely to "the agent" creates a significant void in accountability, leaving enterprises vulnerable to regulatory scrutiny and operational risk. This emerging gap in the audit trail, where the crucial link to "which human told it to" is missing, poses a severe problem that escalates from a minor oversight to a critical compliance failure when an agent deviates from its intended function.

The fundamental issue lies in the current paradigm of software credentialing. Service accounts, designed for machine-to-machine interaction, inherently abstract away individual human identities. When an LLM agent, acting with a degree of autonomy, performs an unauthorized or erroneous action, the log entry "the service account did it" offers no actionable recourse. Corporations cannot discipline a service account, nor can they credibly present such an explanation to regulators who demand clear lines of responsibility. This problem is not theoretical; it is rapidly becoming a concrete concern due to impending legislative deadlines, most notably the European Union’s AI Act.

The Regulatory Imperative: EU AI Act and the Mandate for Human Attribution

The urgency surrounding AI agent accountability is underscored by the EU AI Act, a landmark piece of legislation poised to reshape the landscape of artificial intelligence governance. Article 12 of this comprehensive regulation, specifically targeting high-risk AI systems, mandates that such systems must maintain logs enabling "the identification of the natural persons involved" in an event. This critical provision is set to come into force on August 2, 2026, marking a pivotal deadline for organizations deploying AI. The regulation clearly specifies a "natural person"—an actual human being—not an abstract service account or an agent identifier.

The EU AI Act classifies AI systems as "high-risk" if they are intended to be used in critical sectors like healthcare, law enforcement, employment, financial services, or democratic processes, or if they pose a significant risk of harm to people’s health, safety, or fundamental rights. For such systems, the requirement for human-level attribution in audit trails is non-negotiable. Current logging practices, built around shared credentials, are fundamentally incapable of meeting this standard. The identity of the human initiator is simply not captured at the point of action, meaning no amount of log retention or forensic analysis can retroactively reconstruct this vital piece of information. The absence of this data from the initial capture renders compliance impossible, exposing organizations to potentially severe penalties, reputational damage, and operational disruptions. Beyond the EU, other regulatory bodies globally, such as those in the UK and the US, are also grappling with similar questions of AI ethics, transparency, and accountability, signaling a global trend towards stricter oversight of AI deployments.

The Technical Hurdles: Why Traditional Solutions Fall Short

In the face of this regulatory pressure, initial attempts to solve the attribution problem often gravitate towards seemingly straightforward technical workarounds, but these quickly prove insufficient or insecure. One common instinct is to instruct the LLM model itself to report the identity of the human it is acting for. This might involve embedding the user’s identity within the system prompt or having the agent include it as part of its tool call. However, this approach is fraught with two critical problems.

Firstly, at the protocol level, there is often no native mechanism to carry this identity information. A typical tool call, transmitted over the wire, might look like "name": "export_record", "arguments": .... There is no dedicated field for "who." While some protocols, like Multi-Party Computation (MCP), might permit carrying such metadata, widespread implementation is lacking. OpenAI’s function-calling, for instance, does not include a native identity slot. Without a standardized, secure channel for identity at the protocol level, any attempt to inject this information becomes a custom workaround, prone to inconsistencies and integration challenges.

Secondly, and more critically, anything the model itself emits or processes is susceptible to prompt injection. If the identity originates from, or is managed by, the model, then malicious or unintended inputs (either from the user or from data the agent processes) can potentially rewrite or spoof this identity. Research has shown that even subtle changes, such as altering a tool’s description, can hijack a model’s output more effectively than manipulating its direct output. The model’s output, by its very nature, cannot be treated as a trusted source for identity information. For robust attribution, identity must be stamped by the runtime environment, outside the agent’s reasoning process, and before the model has any opportunity to influence it. This fundamental security principle dictates that trust boundaries must be established around the core identity, preventing any AI component from self-attesting its operational context.

Introducing Crumb: A Framework for End-to-End AI Agent Attribution

Recognizing these critical gaps and the impending regulatory deadlines, a novel runtime framework named Crumb has been developed to provide a robust solution for human-level attribution in AI agent operations. Crumb acts as an essential "flight recorder" for AI agents, meticulously tracking every action back to the human who initiated it, thereby creating an auditable and tamper-evident trail.

At its core, Crumb functions as a mandatory gateway through which every agent tool call must pass. This gateway is not optional; its enforcement is critical to the system’s integrity. When an agent attempts to execute an action via a tool, Crumb intercepts the call. Crucially, it pulls the human user’s identity from a verified session, typically established once at login, ensuring that this identity is never sourced from or influenced by the LLM model itself. This step is fundamental to preventing prompt injection and ensuring the integrity of the attribution.

Once the human identity is secured, Crumb mints a short-lived delegation token. This token, adhering to the RFC 8693 standard, carries both identities: the human as the sub (subject) and the agent as the act (actor). This token is meticulously scoped to the specific resource being called, limiting its power and duration. Simultaneously, Crumb writes a "crumb"—a record of the action—to an append-only, hash-chained ledger. Each entry in this ledger is cryptographically signed using Ed25519, ensuring its integrity and immutability. Only then does Crumb forward the tool call, complete with the delegation token, to the intended resource. A key security feature is that the tool or resource is configured to refuse any call that does not carry a valid Crumb-issued token, effectively closing any bypass routes to the data.

This delegation token is not a custom, proprietary implementation. It is a genuine RFC 8693 token exchange conducted against a standard identity provider. The human’s session token serves as the subject_token, which is then exchanged for a provider-signed composite token (e.g., RS256). The target resource verifies this token against the identity provider’s published JSON Web Key Set (JWKS). This adherence to established standards means Crumb can seamlessly integrate with popular identity providers like Okta, Keycloak, or Zitadel, leveraging their robust security features and avoiding the pitfalls of custom authentication schemes. This standardization significantly enhances interoperability and reduces implementation complexity for enterprises.

Navigating the Complexities of Multi-Agent Delegation

While attributing a single agent’s action to a human is a significant step, real-world AI systems are far more complex. It is common for a human to interact with an orchestrator agent, which then delegates tasks to one or more sub-agents, which in turn call various tools. In such multi-hop scenarios, determining accountability and proving the full chain of delegation when the human is several steps removed from the final action becomes a profound challenge. Most attribution stories and existing frameworks quietly falter at this complexity, and even standards bodies are still working towards comprehensive solutions.

This is where Crumb leverages a powerful, yet often overlooked, mechanism within RFC 8693: the act claim can be nested. Each new actor in the delegation chain wraps the previous one, while the original human initiator remains the sub at the root of the entire chain. By walking this nested structure backward, the system can reconstruct the complete chain of "who-acted-for-whom," ultimately leading back to the natural person who initiated the overall process.

Crumb implements this end-to-end, ensuring that each hop in the delegation process nests the prior actor. This nesting is performed by the identity provider during a real token exchange, not through a developer shortcut or a simplified internal mechanism. The comprehensive crumb record captures this entire chain. Critically, the entire nested structure is signed as a single, cohesive token. This design choice eliminates "per-hop seams" that could be exploited for forgery. Any attempt to rewrite a middle actor in the chain and re-sign it without the proper cryptographic key will cause the entire token to fail verification, as the signature will no longer match the altered content. The chain either holds together perfectly, or it fails verification entirely, providing an ironclad guarantee of integrity.

Consider an illustrative scenario: Alice logs in and authorizes a specific action, read_record. Her request is handled by a planner agent, which then delegates to a researcher sub-agent. The researcher sub-agent subsequently executes the read_record action. Crumb’s trail meticulously traces this action back through both the researcher sub-agent and the planner agent, ultimately verifying that Alice was the originating human. Now, imagine a rogue hop in this chain, perhaps an agent that has been compromised or misconfigured, attempts to call export_record, an action Alice never authorized. While the action might technically run, Crumb’s log will clearly show no human directive behind it. It will flag the action as unauthorized and precisely name the agent chain that executed it. Alice is demonstrably in the record, but she is also provably not accountable for the unauthorized export, providing clear exoneration. A traditional service-account log would simply state "a bot exported the record" and stop there, leaving Alice’s role ambiguous. Crumb, however, clears Alice by name and accurately points to the responsible agents.

Uncompromising Tamper-Evidence: Beyond Internal Controls

The integrity of an audit log is paramount, especially when it forms the basis of accountability. While a signed, hash-chained log provides a strong layer of tamper-evidence, a critical vulnerability remains: if the operator (the entity running the system) holds the signing key, they could theoretically rewrite historical entries, re-sign the entire chain, and present a seemingly valid, yet forged, log. Per-entry verification would pass, as every entry would be validly signed by the operator’s key.

Crumb addresses this sophisticated "operator rollback" attack by implementing an additional, external layer of tamper-evidence. The ledger regularly checkpoints its Merkle root—a cryptographic hash representing the entire state of the ledger—and publishes this root to Sigstore’s public Rekor transparency log. Rekor acts as an immutable, publicly verifiable ledger that timestamps and records cryptographic artifacts.

With this external anchor, the operator rollback attack falls apart. If an operator attempts to rewrite a crumb within their internal ledger and then re-signs the entire chain, while per-entry verification might still pass within their system, the newly generated Merkle root of the tampered chain will no longer match the one that was previously published and timestamped in Rekor. This discrepancy, verifiable by anyone against a neutral, public ledger, immediately exposes the forgery. The demo system for Crumb explicitly illustrates this, allowing users to trigger an operator rollback and observe how the external anchor in Rekor unequivocally catches the attempt at historical revision. This integration with public transparency logs like Rekor elevates the integrity of Crumb’s audit trail to an unprecedented level, providing verifiable proof of its state, even against the system operator itself.

Strategic Scope and Acknowledged Limitations

It is crucial to define Crumb’s precise scope and acknowledge its current limitations, as overclaiming in the complex domain of attribution can undermine credibility. Crumb is designed as a "flight recorder" for AI agents, focusing on recording and proving attribution. It is not a control plane designed to stop unauthorized actions in real-time. That critical function—enforcing policies and preventing disallowed operations—is a distinct and well-funded area, typically handled by specialized authorization solutions like Cerbos, Capsule, or Astrix. Crumb complements these systems by providing the irrefutable audit trail, allowing them to focus on enforcement.

Furthermore, the strength of Crumb’s attribution is directly tied to the gateway’s enforcement. If an agent or system can bypass the Crumb gateway, no crumb will be dropped, and therefore no attribution will occur. Consequently, the gateway must be a real, enforced component of the system architecture, not an optional one.

The multi-hop chain implementation in Crumb, while robust, operates with a caveat concerning cross-issuer delegation across different identity providers. No existing RFC explicitly defines a standard for this specific scenario. Crumb addresses this with a convention: each issuer’s token staples the one before it, and verification proceeds by walking the chain backward to the human, checking each segment against its respective issuer’s key. While this approach demonstrably works in the demo, rejecting various forgery attempts, it rests on an explicit federation trust set. The system operator still explicitly decides which issuers they trust. Calling this a "solved standard" would be an overclaim; it is a pragmatic and secure convention for the current state of identity federation.

Finally, for privacy and to keep sensitive data out of the logs, Crumb’s ledger stores a hash of the arguments, not the raw arguments themselves. The tradeoff is that while it conclusively proves an action happened and who directed it, it does not provide the exact bytes of data that were touched. For full forensic detail, this might require correlating with other, more granular data logs. Additionally, while Crumb can stamp the record with human identity information, it cannot force a non-compliant upstream server to honor this human identity if the server itself does not implement or support Multi-Party Computation (MCP) attribution, which is still rarely adopted.

This transparency about what Crumb is and isn’t is vital in a space where the gap between built capabilities and marketing claims can be significant. Crumb focuses on solving the core attribution problem with a principled, standards-based approach, providing a foundational layer for trust and accountability in AI agent systems.

Conclusion: A Critical Step Towards Accountable AI

The proliferation of LLM agents in enterprise operations introduces unprecedented levels of automation and efficiency, but also novel risks related to accountability and compliance. The looming deadline of the EU AI Act, among other global regulatory pressures, makes the identification of natural persons involved in AI system actions an urgent and non-negotiable requirement. Traditional logging mechanisms and naive attempts at model-based attribution are demonstrably inadequate or insecure.

Crumb offers a robust, standards-based, and tamper-evident solution to this critical challenge. By establishing a mandatory gateway, leveraging verified human identities, employing RFC 8693 delegation tokens, and securing logs with a publicly verifiable transparency ledger, Crumb provides an auditable trail that links every agent action back to its human initiator. Its ability to navigate complex multi-agent delegation chains, clear innocent parties, and expose unauthorized actions represents a significant leap forward in AI governance. While it strategically focuses on attribution rather than control and operates within certain acknowledged limitations, Crumb provides an essential component for building truly accountable and trustworthy AI systems. As AI continues to evolve, foundational solutions like Crumb will be indispensable in ensuring that innovation proceeds hand-in-hand with responsibility and regulatory compliance. The future of AI hinges not just on its capabilities, but on our ability to understand and account for its actions.