Metadata Every LLM Request Should Carry for Cost Governance

Request metadata is a contract, not a report column

When many teams and applications share LLM access, spend and token consumption are usually visible only at the level of an API key or a provider account. Finance cannot assign cost to a team, platform engineering cannot set a meaningful limit, and risk teams cannot say what a given request was permitted to do. The usual cause is that metadata is optional, inconsistent between clients, or added after the fact from partial records.

Treating LLM request metadata as a contract changes the design. The schema is defined once, versioned, and attached when the request is made. Required fields are checked at the point of entry. Requests that fail the check are rejected or flagged rather than repaired later. Every field exists because a specific decision depends on it: who is charged, which limit applies, whether the request is allowed, and what evidence remains afterward.

The second distinction is trust. A client can state that it belongs to the payments team, but only the execution path can confirm it. The rest of this guide sorts fields by the decision they support and by who is able to vouch for them.

The minimum schema, organized by decision

Attribution depends on three fields. Identity is the authenticated user or service principal making the call. Ownership is the team and cost center that answer for that identity. Application is a registered application identifier, ideally with a version. Together they make LLM cost attribution metadata usable: spend can be rolled up by team, by application, or by person without guessing. Ownership should be derived from a registry lookup on identity or application, not typed by the caller, because free-text team names drift and cannot be reconciled.

Environment and model context decide which limits and permissions apply. Environment (production, staging, development) allows separate budgets and stricter rules where real data is present. Model and provider should be recorded twice: the model the client requested and the model and provider that actually served the request. Aliases, fallbacks and routing rules make those values differ, and attribution by model is only accurate if the resolved value is captured.

Purpose and data classification describe intent and sensitivity. Purpose is best expressed as a value from a controlled list, such as customer support drafting or code assistance, so that limits and approvals can be tied to it. Data classification states how sensitive the content is. It can be declared by the client, but a declaration alone is weak, and the execution path should inspect content or apply the application's registered maximum.

Token and usage fields support accounting and rate limiting: input tokens, output tokens, total tokens, and request count over a time window. These come from the provider response or from the execution path's own count, not from the caller. A pre-request estimate is useful for enforcing a budget before the call; the final count settles it afterward.

Policy decision context closes the loop. It records the decision (allow, redact, block, rate limit, escalate), the policy version and rule that produced it, a timestamp, a request identifier, and the schema version. This is what turns attribution data into evidence of what the request was permitted to do.

Where each field is set and validated

The table separates what a client may assert from what the execution path should set or verify. This is a design recommendation, and the exact split will depend on your architecture and identity systems.

• Identity and ownership: Set by the execution path from the authenticated credential, with ownership resolved from a registry. Client assertion is not accepted.
• Application and environment: Client sends the application ID. The path validates it against the registry and derives environment from the credential or route.
• Model and provider: Client states the requested model. The path records the resolved model and provider that served the request.
• Purpose: Client declares a value from a controlled list. The path checks it is permitted for that application.
• Data classification: Client may declare it. The path verifies by inspection or applies the application's registered ceiling.
• Token, usage and policy decision: Set only by the execution path from provider responses, its own counts and its own policy evaluation.

Using metadata to enforce policy in the request path

Metadata has value for limits only when something acts on it before the request reaches the model. In the execution path, a policy can read the verified fields and choose an outcome. A request from a development application carrying restricted data can be blocked. A request with sensitive values in the prompt can be redacted and then forwarded. A team that has used its token allowance for the period can be rate limited. A purpose that requires sign-off can be escalated for human approval. Everything else is allowed.

Each outcome should be written into the decision fields described above. That gives audit evidence at the moment of the decision, without later reconstruction from provider invoices and application logs. Enforced at runtime, not reviewed after the fact, the policy and its record are produced by the same step.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate outcomes applied to individual interactions and tool calls. The evidence this produces is audit-ready and mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. The schema in this guide does not depend on any particular product, but it does depend on enforcement happening where requests actually pass.

Implementation decisions to make early

Most schema failures come from a few early choices. These are the ones worth settling before rollout.

• Version the schema: Publish field definitions in a machine-readable form and stamp each request with the schema version, so old records stay interpretable after fields change.
• Reject at entry: Block or flag requests with missing or invalid required fields instead of back-filling metadata later.
• Use controlled values: Replace free text with registered identifiers and enumerated lists for team, application, environment and purpose.
• Separate usage from content: Keep token and usage telemetry apart from prompts and outputs, so it can be retained and shared under different rules.
• Scale depth to risk: Set the depth of capture and enforcement according to the organization's risk tolerance, as NIST AI RMF Govern 1.3 describes for risk management activities.
• Define retention: Decide how long request records are kept, who can export them, and how privacy handling applies to metadata and logs.

Governance and contractual considerations

The NIST AI RMF is voluntary, so recording and enforcing request metadata is an organizational policy choice unless a contract or sector rule requires it. Its Govern function expects policies to be in place, transparent and implemented effectively. Evidence that metadata-driven policies were applied to real requests is one practical way to show that.

Metadata and logs can also fall within data-handling terms. As of October 2026, draft language in a GSA request for comments, which concerns government contracting and is not a final rule, describes token counts as technical system-level data. The same draft defines Government Data to include metadata and logs, and would require LLM services to support export of interaction history with associated metadata and schema information. Private-sector teams should not read this as a mandate. It does show why schema documentation, retention settings and export formats are worth deciding before a contract or audit asks for them.

Check whether your agreements treat request metadata, logs and token counts as customer data, and whether the schema can be exported alongside interaction records.