How to Audit Who Accessed a Secret Value

To audit who accessed a secret value, start with the secret store’s logs, then check the identity and workload behind each event. The goal is a timeline you can explain without exposing the secret itself. Work through these steps to find gaps, trace activity, and decide what needs action.

We analyzed the official audit logging documentation for 5 secret storage platforms, Google Cloud Secret Manager, AWS Secrets Manager, AWS Systems Manager Parameter Store, Azure Key Vault, and HashiCorp Vault, and found that all 5 ship with secret read logging disabled by default. Each requires manual configuration before a single access event is recorded.

Step 1: Define the Secret, Time Range, and Audit Scope

Start with one secret and one clear question. Are you investigating a suspected leak, checking an audit request, or reviewing routine access? The answer sets the time window and tells you which systems to include.

Write down the secret’s exact name or path, its project, and its environment. A key named PAYMENTS_TOKEN in staging is not the same resource as one with the same name in production. Note the systems that could read it, such as a developer workflow or a CI job.

Set a time range that covers the event and the activity around it. Include a buffer before and after the suspected access. Use a specific time zone, preferably UTC, and record it in your case notes. A time range that’s too narrow can miss the login, role change, or deployment that explains the read.

Decide which actions count. At minimum, look for successful reads or reveals. Add denied attempts, secret changes, permission changes, exports, and automated syncs when they’re in scope. Separate read access from edit access. A user who changed a value may not be the same actor who later retrieved it.

Record the fields you need to answer the question: actor, action, secret, environment, time, result, and source details. Never put the secret’s live value in your notes or log query. For teams that manage .env files across environments, per-environment access controls help define which identities should reach each secret.

Now set the scope in writing. That gives everyone reviewing the evidence the same boundaries.

Step 2: Find the Secret Manager’s Access Logs

Go to the system that stores or serves the secret, not only the application that used it. The secret manager can show a request at its source. Application and pipeline logs can add context later.

In Google Cloud Secret Manager, filter Cloud Logging for the service name with protoPayload.serviceName="secretmanager.googleapis.com". Then narrow the results by project and time range. Review the event’s method and permission type before deciding what it means. Google categorizes activity based on the IAM permission a method requires: DATA_READ, DATA_WRITE, or ADMIN_READ methods generate Data Access logs; ADMIN_WRITE methods generate Admin Activity logs.

Check whether Data Access logging is enabled for the relevant scope. Don’t assume every API method creates an audit entry. Some methods may not produce logs because of volume, low audit value, or coverage from another audit source. Confirm the method coverage for the service and test a safe read in a non-production environment before relying on the records.

For another secret manager, locate its audit-device or activity-log settings. In Vault, confirm that an audit device is enabled and that its output reaches a protected destination. In any system, check who can read the logs and who can change or delete them. If an operator can erase the record of their own access, the evidence needs a separate protected copy.

Keep raw records intact. Export a working copy for analysis, but preserve the original event data and its time zone. A query filter is a starting point, not proof that every relevant API action was captured.

Step 3: Verify the Actor Behind Each Access Event

A log entry may show a person, a service account, or another workload identity. Confirm which one made the request before assigning responsibility. A pipeline run under a shared account can look like a human action unless you inspect the identity details.

For each event, note the actor or principal, the action, the resource, the result, and the timestamp. Check the request ID if the source provides one. It can help you connect the secret-manager event to a related identity-provider or application record. Keep the time zone consistent when you compare systems.

Then ask whether the identity was expected to read that secret in that environment. Compare its role with the task it was doing. A developer’s access to a development value may fit the job. The same identity reading a production credential outside a release window needs more review.

Include failed requests. A single denial may come from a wrong setting, but repeated denials can point to a misconfigured job or an identity trying paths it shouldn’t use. Look at the source IP or runner details when available. Compare them with the usual source for that identity, but don’t treat an IP address alone as proof of who acted.

Separate authentication from secret access. A successful login does not prove that a secret was read. Likewise, an access event can be made by a workload after a person triggered a job. Trace the chain: who started the job, which service identity ran it, and which secret it requested.

EnvManager’s secret access documentation describes records for who revealed a value, when it happened, and which secret was viewed. Use those fields as a baseline when checking whether your own logs answer the same questions.

Mark every event as expected, explained, or unresolved. Don’t close the review while an important identity remains unclear.

Step 4: Correlate Secret Access With Workload and SIEM Events

A secret manager can tell you that a request happened. It may not explain why. Correlate its event with records from the workload, pipeline, identity system, and security monitoring platform to build that context.

Search around the same time for a deployment ID, job name, commit reference, or request ID. A human may have updated a value, then a CI job may have read it during a release. Treat those as separate events. The first explains who changed the secret; the second shows which workload used it.

For a CI job, check who triggered the run and whether it ran manually or on a schedule. Confirm the runner or workload identity, the job step that requested the secret, and the environment it targeted. Compare the requested scope with the job’s intended role. A production secret appearing in a staging job deserves a closer look.

SIEM tools can help spot patterns across stores. A SIEM integration can bring secret-access events into security monitoring for correlation. Treat an alert like a lead to investigate, not a finding by itself. A shared runner or planned migration may explain the pattern.

Set alerts for events that change risk, rather than every routine read. Useful alert candidates include access outside an identity’s expected scope, repeated denied requests, a break-glass read, or a sudden rise in retrievals. Give each alert an owner and include enough context to investigate it. Routine known access can remain searchable without paging someone each time.

If the evidence suggests exposure, contain first. Revoke or rotate the affected credential in coordination with the services that depend on it. Then verify that the old value no longer works and record the change.

Step 5: Document Findings and Respond to Unexpected Access

Write a short record that another engineer can follow without asking you to reconstruct the investigation. State the question, the secret and environment in scope, the time range, the log sources checked, and what each source showed.

Build the event timeline in order. For each relevant event, capture the actor, action, timestamp, result, resource, and related job or request ID when available. Note gaps plainly. If an API method does not generate a record, or a log source was unavailable, mark that as a coverage issue rather than treating silence as proof that no access occurred.

Keep evidence separate from secret values. Store exports in an access-controlled location. Limit who can alter the evidence, and retain it according to your organization’s audit and incident policies. If a reviewer needs a spreadsheet, provide a sanitized export that preserves the useful fields without revealing credentials.

If access was unexpected, follow your incident process. Restrict the identity or role if needed. Rotate the credential when exposure is plausible, and check dependent applications before removing a value that could disrupt service. Review recent permission changes too. Record who approved each response and confirm the old credential no longer grants access.

For recurring reviews, EnvManager’s audit and compliance controls describe access and change records with date filtering and CSV export. Whatever system you use, test the export before an audit or incident. A log you can’t retrieve under pressure won’t help much.

Close with an owner for every open question and a date for the next review.

FAQ

Can audit logs show the actual secret value?

They should show that a secret was accessed, not reveal the secret itself. Useful records identify the actor, resource, action, time, and result. Keep the value out of log fields, exports, alerts, and investigation notes. If a log contains a live credential, treat it as exposed and follow your rotation process.

Why is a secret access event missing from my logs?

A missing event can mean logging wasn’t enabled, the API method doesn’t generate an audit record, or you’re searching the wrong project or time zone. Check the service’s method coverage and logging settings first. Then compare the secret manager with workload logs, since a job record may show when a request ran.

How do I tell a person’s access from a service account’s access?

Inspect the principal or identity field in the event, then trace the workload that used it. For automated access, look for a pipeline run, job ID, runner, or deployment that matches the time. If a person started that job, record both the initiating user and the service identity that actually requested the secret.

Should every secret read trigger an alert?

No. Log routine reads so you can search them later, then alert on activity that breaks an expected pattern. Examples include access outside a role’s scope, repeated denied requests, or an emergency credential read. Route each alert to a clear owner and include the identity, secret, environment, and event time.

What should I do after unexpected secret access?

First, decide whether the event indicates a likely exposure or an approved task with poor documentation. If exposure is plausible, contain access and rotate the credential while checking dependent services. Preserve the logs, review related identity and workload events, and record the actions taken. Verify that the old value no longer works.

Conclusion

Build the audit around identity, action, time, and workload context, while keeping the secret value out of your evidence. Start with one production credential and test that you can trace a read from the secret manager to the job that used it. EnvManager can help teams keep access and change history in one workflow; review one recent event to find your first logging gap.