Securing the LLM observability platform itself: admin roles, service accounts, keys, logs and lifecycle

An LLM observability platform ends up holding the most sensitive text your AI applications ever see, plus the keys that write to it and the prompts that steer production, so whoever controls it can read everything and quietly change behaviour. Tracing, evaluation and prompt management tools collect prompts, completions, retrieved documents, tool calls and system instructions from every instrumented application. Many also store model API keys for evaluations and serve prompt versions back to production. This guide is for AI platform engineers, ML operations leads and security architects who run, or are about to run, such a platform, hosted or self-hosted. It covers admin roles, the platform's own service accounts and keys, the data it stores, its audit trail, hardening and lifecycle. It does not repeat how to instrument applications or what to detect from LLM telemetry; that is in the LLM Observability Guide. It is vendor-neutral: confirm the exact setting names in your vendor's documentation.

Key takeaways

• Classify the trace store as a sensitive data store. Captured prompts and outputs contain personal data, customer records and pasted secrets, so the platform needs the access control, retention and deletion rules of a production database.
• Split write, read and admin credentials. Ingest keys should only write, read keys should only read the projects they need, and admin rights should sit with a handful of people using SSO and phishing-resistant MFA.
• Treat prompt management as a production change path. If the platform serves prompt versions to applications, publishing a prompt is a deployment and needs the same approval and audit as code.
• Remember the keys it holds. Evaluation and playground features often store model provider API keys, which are spendable credentials; scope, cap and rotate them.
• Keep the platform's own audit log elsewhere. Role changes, key creation, prompt publishing, retention changes and bulk exports must land in a log store that platform admins cannot alter.

What the platform holds and why it matters

OWASP LLM02:2025 Sensitive Information Disclosure and LLM07:2025 System Prompt Leakage are usually read as risks in model output. They apply equally to the observability platform, which keeps a copy of both. The OpenTelemetry GenAI semantic conventions (status: Development, checked November 2026) mark attributes such as gen_ai.output.messages, gen_ai.system_instructions and gen_ai.tool.definitions as opt-in, and warn that output messages are likely to contain sensitive information including user and personal data. Once someone opts in, the platform becomes the place where that content is concentrated.

Admin roles and console access

In our experience, observability products are often adopted bottom-up by one team with a free tier, then become shared infrastructure. Reset the access model when that happens.

• Role design: separate at least four duties: organisation admin (SSO, roles, retention, integrations, billing), project owner (keys and settings for one application), engineer or viewer (read traces for owned projects) and prompt publisher (promote prompt versions to production labels). The ability to change retention or delete projects is as sensitive as admin rights, because it destroys evidence.
• Project boundaries: map projects to applications and data classifications, not to teams of convenience. A customer support assistant that handles personal data should not share a project with an internal coding assistant, because project membership usually grants read access to every trace inside it.
• Authentication: use SSO through your identity provider with phishing-resistant MFA, then disable password logins and invitations from outside your domain where the product allows it. The CISA and FBI Secure by Demand guide suggests buyers ask whether standards-based SSO is offered at no additional cost and whether MFA or passkeys are on by default at no cost. Keep one documented break-glass account. See the Break-Glass Account Guide.
• Provisioning: drive role assignment from identity provider groups (SCIM or group claims) so leavers lose access automatically. Review direct assignments every quarter (our recommendation).
• Trusted devices: the NCSC secure system administration principles start with gaining trust in your management devices. Administer the platform from managed devices, and for self-hosted deployments reach the admin interfaces only from a privileged access network. See the Privileged Access Workstations Guide.
• Vendor support access: for hosted platforms, find out whether vendor staff can view your traces, how that access is granted and whether it appears in your audit log. Prefer customer-approved, time-bound support access.

Service accounts, keys and the credentials it holds

The platform is both a consumer and a holder of non-human identities. Every one of them belongs in your NHI inventory with an owner, scope and expiry.

• Write-only ingest: the main design decision. A leaked ingest key, which ships inside application configuration, should only let an attacker add noise. Rate limit ingest per key and alert on sudden volume changes.
• Keep secrets out of the payload: configure SDKs and the collector so authorisation headers, API keys and connection strings are never recorded as span attributes. OWASP LLM07 is clear that credentials and connection strings should not sit in system prompts; if they do, the observability platform will copy them.
• Evaluation keys are spendable: a stolen model key is a common starting point for LLMjacking. Route evaluation calls through your AI gateway where possible so spend caps and logging apply. See the LLMjacking Guide and the AI Gateway and LLM Gateway Guide.
• Rotation: rotate static keys at least every 90 days and immediately when an application owner leaves or a repository is exposed (our recommendation). See the API Key Management Guide and the Secrets Management Guide.

Protecting captured content

The best protection is not collecting content you do not need. Where you do collect it, put the platform's own controls around it.

1. Decide per project: metadata-only by default; turn on content capture for a project only after a data protection review names the purpose and retention. The conventions make content attributes opt-in, so a project with content on is a deliberate choice that should be recorded.
2. Redact before it leaves your network: the OpenTelemetry Collector configuration best practices recommend the redaction processor, which removes attributes not on an allowed list and masks values matching blocked patterns such as card numbers, before export. Redacting in the collector covers every backend, not just one SDK.
3. Restrict who can see content: where the platform offers it, give most engineers a role that sees metadata and scores but not raw prompts and outputs, and reserve content access for named investigators.
4. Encrypt and locate: confirm encryption at rest, data residency and backup location. For self-hosted deployments, encrypt the database and object storage and keep keys in your key management service. If customer-managed keys are offered, weigh revocation control against the outage risk of a disabled key.
5. Set retention by data class: keep metadata as long as audit needs require and content for the shortest useful period. Confirm that deletion covers backups, exported datasets and evaluation copies, because, in our view, a trace store holding personal data is likely to fall within scope of erasure requests. See the AI and Privacy Guide.
6. Control datasets: production traces copied into evaluation datasets inherit the same sensitivity but often escape retention rules. Apply the same project boundaries and expiry to datasets.

Prompt management and evaluation as a change path

Many platforms let applications fetch the current prompt by name and label at runtime. That is convenient, and it means a console user can change what a production assistant is told to do without a code review. Treat it like a deployment pipeline.

• Protect production labels: only the prompt publisher role can move the production label, ideally with a second approver for customer-facing or tool-using applications.
• Review diffs: require a visible diff and a linked ticket for each promotion, and keep the previous version one click away for rollback.
• Pin in high-risk applications: for agents that can take actions, pin a prompt version in the deployment and promote by release rather than fetching the live label.
• Cache and fail safe: decide what an application does if the platform is unreachable: use a cached or bundled prompt rather than failing open to an empty prompt.
• Evaluators can be manipulated: LLM-as-judge evaluators read traced content, which may include injected instructions (OWASP LLM01:2025 Prompt Injection). Do not let evaluation scores alone gate a production release.

The platform's own audit log

• Export it: stream the audit log to your SIEM or a log archive the platform's admins cannot modify. NIST SP 800-53 AU-9(2) covers storing audit records on a separate system and AC-6(9) covers logging privileged functions. The NCSC principles ask you to log all administration activity and audit it to confirm only legitimate, approved actions were taken.
• Retention: Secure by Demand asks SaaS providers to retain and make available security logs for at least six months at no additional charge. Check what your plan includes and export if it is shorter.
• Ask before buying: some products log trace data in detail but record admin actions only on higher tiers. Make audit log export a procurement requirement. See the AI Agent and LLM Observability Buyer's Guide.

Hardening a self-hosted deployment

• Collector: the OpenTelemetry Collector guidance recommends binding receivers to localhost or a specific interface rather than 0.0.0.0 (localhost is the default host from v0.110.0), using TLS and the Collector's authentication for receivers and exporters, running as a non-root user, keeping tokens and private keys in a secret store or encrypted filesystem, and building a distribution with only the components you need.
• Network: keep the trace database, object storage and queue on private networks; expose only the ingest endpoint and the console, each behind TLS and, for the console, SSO.
• Bootstrap secrets: replace any sample secrets, salts and encryption keys from quick-start files before the first production trace, and keep them in your secrets manager.
• Updates: apply vendor security updates promptly, subscribe to the project's or vendor's security advisories page, and track the version in your asset inventory.
• Backups: backups hold the same content as production; encrypt them, restrict access and include them in retention and deletion.

Lifecycle: buy, deploy, run, retire

Roll back a hardening change, such as narrowing a key scope, by keeping the previous scope documented and re-granting only the specific permission a failing job reports, never by issuing an organisation-wide key.

Detection and measurement

• Key misuse: read or admin keys used from addresses outside your workloads, or an ingest key suddenly writing to a different volume profile.
• Quiet collection changes: content capture switched on, or redaction removed, outside a change ticket.
• Unexplained prompt promotions: production labels moved by someone outside the publisher group or without a linked ticket.
• Evidence loss: retention shortened or projects deleted.

Metrics that show the controls are working:

1. Number of organisation admins (target: five or fewer, our suggestion) and percentage of users provisioned through SSO groups.
2. Percentage of projects capturing content with a recorded data protection review.
3. Percentage of ingest keys that are write-only and per application.
4. Read and admin keys older than 90 days without rotation (target: zero).
5. Percentage of production prompt promotions with a linked approval.
6. Days of platform audit log available in the SIEM.

Framework mapping

Common failure patterns

• One key for everything: a single organisation key with read and write rights is pasted into every application, so any leaked configuration file exposes every trace.
• Content on by default: a quick-start integration records full prompts and outputs in production, and nobody notices until an access request or incident.
• Prompts edited in the console: a production assistant's instructions change with no review, and the change is only visible in the platform's own history.
• Production model key in the playground: evaluations reuse the main provider key with no spend cap.
• Datasets that never expire: production traces copied into evaluation datasets outlive the retention policy for the source data.
• Audit trail left inside the tool: the only record of key creation and exports sits in the console an attacker controls.

Practitioner checklist

• Classify the platform as a sensitive data store and record its data classes, residency and retention.
• Enforce SSO with phishing-resistant MFA, provision roles from identity provider groups and keep one tested break-glass account.
• Separate organisation admin, project owner, viewer and prompt publisher roles, and limit raw content access to named investigators.
• Issue write-only ingest keys per application and environment, and scoped, expiring read keys.
• Give evaluations a dedicated, spend-capped model provider key, preferably through your AI gateway.
• Default projects to metadata only and redact in the collector before export.
• Protect production prompt labels with approval, diffs and pinning for action-taking agents.
• Export the platform's audit log to a store its admins cannot change, and alert on keys, exports, retention and capture changes.
• Review roles, keys, content-enabled projects and datasets every quarter, and keep a decommissioning checklist.

Standards and references

• OWASP: Top 10 for LLM Applications 2025
• OpenTelemetry: Semantic Conventions for Generative AI
• OpenTelemetry: Collector configuration best practices
• NCSC: Secure system administration
• CISA and FBI: Secure by Demand Guide
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: LLM Observability Guide · AI Agent and LLM Observability Buyer's Guide · LLMjacking Guide · Secrets Management Guide · Securing the identity threat detection and response (ITDR) tool itself