New Relic keys sit in agent configuration files, container environments and CI variables across every monitored host, so they leak often, and a leaked user key lets the holder read your telemetry and change your account. New Relic splits its credentials into ingest keys (license and browser keys, mobile app tokens, older Insights insert keys) that write data, and user keys that query data through NerdGraph and change configuration. The response to each is different: an ingest key leak is about data integrity and cost, a user key leak is about data exposure and account changes. This guide covers the key types, how to recognise them, what each reaches, how to find misuse with NrAuditEvent, the deactivate, replace and delete sequence, and the controls that keep keys contained. It is for observability, platform and security teams that administer New Relic organisations. For the general process see the Leaked Credential Response Playbook.
Key takeaways
- Deactivate first, delete later. New Relic's API Keys page can deactivate any key type except the original account key, which stops authentication immediately and is reversible, so you can contain before you know every dependency.
- User keys act as the user. A leaked user key can query everything that user can see through NerdGraph and make the changes that user can make, so treat it as an account compromise for that user.
- Replace every key of a compromised user. New Relic's guidance is to replace all keys associated with or created by that user, not just the one found.
- Original account keys need support. The license and browser keys created with each account cannot be deleted or deactivated in the UI; New Relic support regenerates them, so do not use them in production.
- GitHub does not alert New Relic. The four New Relic secret types are scanned only in private repositories with GitHub Secret Protection, not through the public partner programme, so public leaks depend on your own scanning.
How identity and access work in New Relic
A New Relic organisation contains one or more accounts. People sign in through an authentication domain (password or SAML SSO) and receive roles on accounts. Programmatic access uses keys managed on the API Keys page (one.newrelic.com, one.eu.newrelic.com or one.jp.newrelic.com depending on data centre) or through NerdGraph's apiAccess mutations.
| Key | Used for | Tied to | What a holder can do | Recognising it |
|---|---|---|---|---|
| License key (Ingest - License) | Reporting almost all data: APM, infrastructure, logs, metrics, events, traces | An account; any number can be created | Send arbitrary data to the account | No distinctive prefix in Gitleaks' default rules; often in newrelic.yml, newrelic-infra.yml or NEW_RELIC_LICENSE_KEY |
| Browser key (Ingest - Browser) | Browser monitoring data | An account | Send browser data; it is embedded in pages by design | Gitleaks rule keyed on NRJS- |
| Mobile app token | Mobile monitoring data | One mobile app | Send mobile data for that app; it ships inside the app | Cannot be deleted or added; replaced by re-authorising the app |
| User key | NerdGraph and REST API: querying and configuration | One user | View data and make account changes with that user's permissions | Gitleaks rule keyed on NRAK- |
| Insights insert key (legacy) | Ingest through the metric, event, log and trace APIs | Organisation | Send data | Gitleaks rule keyed on NRII- |
| Insights query key (legacy) | Querying event data | Organisation | Read event data | GitHub type new_relic_insights_query_key |
| REST API key (legacy) | REST API v2 | Account | Depends on account access | GitHub type new_relic_rest_api_key |
| Pixie API key | Custom applications on the Pixie platform | Pixie organisation | Call Pixie APIs | Cannot be modified; create new, delete old |
After creation, the API Keys page shows only the first eight characters of an ingest key or a user key. You can retrieve the full value of keys you own through NerdGraph, but keys you create for other users are only ever shown truncated. Those eight characters are what you match a leaked value against.
Admin roles and privileged access
- Key read and key edit access: needed to view last-used dates and owning teams, and to assign owning teams to ingest keys.
- Manage all user API keys: the permission needed to deactivate or reactivate another user's key. Make sure your incident responders hold it before an incident, because deactivating your own key needs no extra permission but deactivating someone else's does.
- Account administrators: replace the legacy Insights insert and query keys, which apply to the whole organisation.
- User management: removing a user from New Relic disables every user key associated with that user ID, which is the fastest containment when a person's account or laptop is compromised.
The privileged credential in New Relic is effectively any user key belonging to someone with broad roles, because the key inherits them. Automation should run as dedicated users with only the roles the integration needs, not on an administrator's personal key.
Integrations, API tokens and service accounts
Ingest keys are spread across every host and container you monitor, which makes them impossible to keep perfectly secret. The goal is to make each one replaceable without an outage:
- Create additional license keys per environment, cluster or team rather than using the original account key, since the original cannot be deleted or deactivated by you. NerdGraph allows up to 1,000 keys of each ingest type, which leaves ample room for rotation.
- Set owning teams on license ingest keys (in the UI or with
owningTeamIdsin NerdGraph) so responders know who to call before deactivating a key that stops their data. - Use dedicated user keys per integration (Terraform providers, CI deployment markers, dashboards as code, AI assistants that query telemetry), each on a user with minimal roles.
- Retire legacy keys: Insights insert and query keys and REST API keys are older types that New Relic does not recommend; move their consumers to license and user keys.
Telemetry is a data store in its own right. Logs and traces often contain request headers, tokens and personal data, so a read-capable key can be a credential harvesting tool. The Privacy in Security Logging and Monitoring Guide and the JWT and Session Tokens in Code and Logs Guide cover keeping secrets out of telemetry in the first place.
Logging and detection
Secret scanning coverage
| GitHub secret type | Public repos (partner) | Private repos with Secret Protection | Push protection |
|---|---|---|---|
new_relic_license_key | No | Yes | No |
new_relic_personal_api_key | No | Yes | Yes |
new_relic_rest_api_key | No | Yes | Yes |
new_relic_insights_query_key | No | Yes | Yes |
None has a validity check. Gitleaks' default rules (checked 28 October 2026) match NRAK- user keys, NRII- insert keys and NRJS- browser tokens, but only when a "new relic" style word sits near the value, and they have no license key rule. Add a custom rule for license keys anchored on the variable names and configuration keys your agents use, and scan container images and Helm values as well as repositories. See the Git Secret Scanning Guide.
Finding misuse with NrAuditEvent
NrAuditEvent records user additions and deletions, permission changes, logins and logouts, account changes made through the API, synthetic monitor changes, dashboard creation, updates and public sharing, and workload changes. Every NerdGraph key mutation (create, update, delete) also produces an NrAuditEvent. All accounts can query 13 months of history, and user, permission and login events are written only to the organisation's parent (reporting) account, so query there.
| Question | What to query |
|---|---|
| What did API keys change? | actorType = 'api_key', returning actionIdentifier, description, targetType, targetId, actorAPIKey |
| What did the compromised user do? | actorType = 'user' filtered on actorEmail or actorId |
| Who logged in, and when? | actionIdentifier = 'user.login' in the parent account |
| Were new accounts created? | actionIdentifier = 'account.create' |
| Were synthetic scripts altered? | actionIdentifier = 'synthetics_monitor.update_script' |
| Were keys created or changed? | Key mutations in the incident window, faceted by actionIdentifier |
Synthetic monitor scripts deserve attention: scripted monitors often hold secure credentials for logging in to your applications, and a changed script can send them elsewhere. For ingest key misuse, look outside the audit log: unexpected entities, hosts or services appearing, unusual ingest volume or cost per key, and data arriving from networks you do not own. Use New Relic alerts on NrAuditEvent so key creation and API-driven changes page someone.
Metrics that show it is working
- Time to deactivate a leaked key after the first alert.
- Original account keys in use: hosts or services still reporting with the original license key, trending to zero.
- Stale user keys: user keys with no use in 90 days, from the Last used column.
- Ownerless license keys: ingest keys without an owning team.
- Legacy key count: remaining Insights and REST API keys.
Leak response
- Identify the key. Use the prefix, file and variable name to classify it, then match its first eight characters on the API Keys page (filter by type and account) to find the owner, account and owning team.
- Contain: select Deactivate key from the key's menu, or set
enabled: falsethrough NerdGraph. Deactivating a license key stops ingestion for everything using it, so warn the owning team, but do it anyway if the exposure is public. - For a user key, widen the scope: deactivate and replace every key associated with or created by that user. If the person's account may be compromised, remove or disable the user (which disables all their user keys) and reset access at the identity provider.
- Replace: create a new key of the same type (Ingest - License, Ingest - Browser or User), update agents, scripts and secret stores, confirm data or API calls succeed, then delete the old key. License keys cannot be edited, only replaced.
- Original account keys: contact New Relic support to regenerate them, and in parallel move consumers onto user-created keys so you never need support for this again.
- Mobile app tokens: re-authorise the app in New Relic to generate a new token and ship an update; old app versions will keep the old token.
- Investigate: run the
NrAuditEventqueries above across the exposure window, review dashboards made public, synthetic script changes, new users and permission changes, and check for injected or anomalous telemetry that could mislead alerting. - Assess data exposure for read-capable keys: what logs, traces and events the user could query, and whether they contain secrets or personal data that now need rotation or notification.
- Close out with the evidence fields in the Secrets Rotation Runbook Template.
Hardening baseline
- Inventory: list ingest and user keys per account, assign owning teams, and flag original account keys, legacy keys and user keys without recent use.
- Migrate off original keys: issue new license keys per environment and roll them out through your secret manager, cluster by cluster.
- Scream test before delete: deactivate the old key for a defined window, watch for broken ingestion, reactivate if needed, then delete. Deactivation is the rollback path.
- Dedicated automation users: one per integration, minimal roles, and their keys in a secret manager rather than in pipeline variables.
- Prepare responders: grant "Manage all user API keys" to the security on-call group and test deactivation on a non-production key.
- Alert: NRQL alert conditions on
NrAuditEventfor key mutations,actorType = 'api_key'changes, user additions and public dashboard sharing. - Keep secrets out of telemetry with agent attribute exclusions and log obfuscation, so a read key exposes less.
Small teams can get most of the value from two steps: replace the original license key with per-environment keys and turn on scanning. Larger organisations should manage keys through NerdGraph as code, enforce owning teams on every ingest key, and feed NrAuditEvent to the SIEM alongside identity provider logs.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | MITRE ATT&CK |
|---|---|---|---|---|
| Key inventory, owning teams and rotation | IA-5, AC-2 | PR.AA-01 | A.5.17 Authentication information | T1078 Valid Accounts |
| No keys in config, images or code | IA-5(7) | PR.DS-01 | A.8.4 Access to source code | T1552.001 Credentials In Files |
| Least privilege for user keys | AC-6 | PR.AA-05 | A.8.2 Privileged access rights | T1528 Steal Application Access Token |
| Audit event monitoring | AU-6, SI-4 | DE.CM-09 | A.8.16 Monitoring activities | T1098.001 Additional Cloud Credentials |
| Telemetry integrity | SI-4 | DE.AE-03 | A.8.15 Logging | T1565.001 Stored Data Manipulation |
Common misconfigurations
- Everything on the original license key: the one key you cannot deactivate yourself is the one in every agent.
- An administrator's user key in Terraform state: state files and CI logs carry the key, and it inherits administrator reach.
- Replacing only the found key: the same person's other keys, created alongside it, stay live.
- Querying the wrong account: login and permission events live only in the parent account, so investigations run in a child account miss them.
- Assuming GitHub will catch it: no public partner alerting exists for New Relic keys, and the license key type has no push protection.
- Secrets in logs: application logs forwarded with bearer tokens or passwords, turning every query key into a credential store.
Practitioner checklist
- Replace original account ingest keys with per-environment license keys that you can deactivate.
- Assign an owning team to every license ingest key.
- Give each integration its own user on minimal roles and its own user key.
- Grant "Manage all user API keys" to incident responders and rehearse deactivation.
- Add custom scanning rules for license keys and enable push protection in private repositories.
- Alert on key mutations and
actorType = 'api_key'changes inNrAuditEvent, queried in the parent account. - Remove legacy Insights and REST API keys.
- Exclude secrets and sensitive attributes from logs and traces.
- After any user key leak, replace every key that user owns or created.
Standards and references
- New Relic Docs: New Relic API keys
- New Relic Docs: NerdGraph tutorial, manage API keys
- New Relic Docs: NrAuditEvent, query account audit logs
- GitHub Docs: Supported secret scanning patterns
- Gitleaks: Project repository and default rules
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Datadog API and Application Keys Security Guide · Leaked Credential Response Playbook · Sentry credentials · Developer Secret Scanning Triage