Auditing a Key Several Teammates Share: Attributing Requests Without Per-User Logins

The Challenge of Shared Keys

Using one API key across a team simplifies setup but complicates attribution. Without per-user logins, you cannot rely on the aggregator to automatically distinguish who made which request. However, you can implement request-tagging practices to enable later log review and maintain accountability.

Why Attribution Matters

Accurate attribution helps with:

• Cost allocation: Assigning usage costs to projects or departments.
• Performance analysis: Understanding which team members or use cases drive API calls.
• Security auditing: Detecting anomalies or unauthorized usage.
• Credit distribution: If your team contributes to the aggregator's ecosystem, ensuring fair credit distribution.

Request-Tagging Practices

Since the aggregator does not enforce per-user authentication, you need to embed identifying information within each request. Here are methods that work without modifying the aggregator's core behavior.

Custom Headers

Most API clients allow adding custom HTTP headers. Include a header like X-Request-Source with a value that identifies the user, service, or project. For example:

• X-Request-Source: alice
• X-Request-Source: billing-service

The aggregator may not process these headers, but they appear in your application logs and can be correlated with API call logs if the aggregator logs full requests. Check your aggregator's documentation for header logging support.

Metadata in Request Body

If the API accepts a metadata field (common in many LLM APIs), include a user identifier there. For instance, OpenAI-compatible endpoints often support a user parameter. Use a consistent, unique string per team member or service. This metadata is typically returned in responses and may appear in usage logs.

Query Parameters

For GET requests or when supported, append a query parameter like ?tag=alice. This is visible in server logs and easy to parse. Ensure it doesn't interfere with API functionality.

Logging on Your Side

Implement client-side logging that records:

• Timestamp
• User or service making the call
• Model used
• Token counts (if available)
• The unique request tag

This creates an independent audit trail. Combine it with the aggregator's usage dashboard for reconciliation.

Log Review Workflow

To make later log review feasible, establish a routine:

1. Centralize logs: Aggregate application logs from all team members into a central system (e.g., a log management tool).
2. Correlate with aggregator logs: If the aggregator provides request logs, match entries using timestamps and tags. If not, rely on your own logs.
3. Analyze patterns: Look for unexpected usage, cost spikes, or model preferences per user.
4. Reconcile costs: Map aggregator charges to internal tags. Remember that users pay official price × 1.3, so your internal cost allocation should reflect that multiplier.
5. Distribute contributor credit: If your team contributes to the aggregator's ecosystem, use the same tags to attribute credit. Contributors receive official price × 1.1 (or × 1.2 for premium) in USDC. Ensure fair distribution based on tagged usage.

Best Practices

• Standardize tags: Use a consistent naming convention (e.g., team-member-name, project-id).
• Automate tagging: Integrate tagging into your SDK or internal API wrapper to avoid human error.
• Educate the team: Ensure everyone understands the importance of including tags.
• Regular audits: Schedule periodic reviews to catch missing or incorrect tags.
• Secure tags: Avoid including sensitive information in tags, as they may be logged in plain text.

Limitations and Alternatives

Request tagging is not foolproof. A malicious actor could forge tags, and tags may not be logged by the aggregator. For stronger attribution, consider:

• Per-user sub-keys: Some aggregators allow creating multiple keys under one account. Check if yours supports this.
• Proxy layer: Route all requests through a lightweight proxy that authenticates users and adds tags. This adds complexity but provides robust attribution.
• Separate keys per team: If feasible, issue individual keys. The aggregator's model of one key for many models doesn't preclude multiple keys.

Conclusion

Sharing one aggregator key is convenient, but with thoughtful request-tagging and disciplined log review, you can maintain accountability. Combine client-side logging with any aggregator-provided logs, and use tags to allocate costs and contributor credits fairly. While not as strict as per-user logins, these practices offer a practical balance for many teams.