Exposed cloud keys and tokens expose the limits of secrets management

At a glance

What this is: This is an analysis of how exposed cloud keys and tokens turned public web assets into large-scale identity exposures across Tata Motors systems.

Why it matters: It matters because IAM, NHI, and platform teams need to treat secrets sprawl, token scoping, and exposure detection as core governance controls, not after-the-fact hygiene.

By the numbers:

• The exposure granted access to over 70 TB of fleet telemetry spanning decades.

👉 Read Unosecur's analysis of exposed cloud keys and token exposure

Context

Cloud secrets are credentials that should never be exposed in browser code, public repositories, or front-end scripts. In this case, AWS keys and third-party tokens were embedded in public assets, which meant access controls were bypassed before any traditional security boundary could help.

The identity governance problem is broader than one company. When secrets sit in client-side code, access scope, token validity, and revocation discipline become the real control plane, and that is the part many programmes still manage too late.

Key questions

Q: How should security teams handle exposed cloud keys before attackers use them?

A: Security teams should assume exposed cloud keys are active until proven otherwise. The first step is to revoke and rotate the key, then check CloudTrail, storage access logs, and analytics audit trails for any use after disclosure. Containment must include scoping review, not just credential replacement, because a valid key can reveal over-permissioned access paths.

Q: Why do exposed API tokens create a larger risk than a single leaked password?

A: API tokens often carry machine-level permissions that can reach storage, dashboards, or partner systems without interactive prompts. That makes them harder to detect and more damaging when leaked, because they may enable bulk data access or impersonation at scale. The risk grows further when token lifecycle ownership is unclear.

Q: What breaks when secrets are embedded in browser code?

A: The secret stops being secret. Anyone who can load the page can inspect the bundle, recover the credential, and use it until the token is revoked. Client-side embedding also removes trust in any claim of encryption, because the same code often contains the logic needed to recover the secret locally.

Q: How do IAM teams reduce blast radius after a cloud credential exposure?

A: IAM teams reduce blast radius by combining least privilege, short-lived credentials, and fast revocation with continuous monitoring. They should also verify whether the exposed identity can enumerate storage, assume roles, or impersonate analytics users. If the access scope is broad, the response must include permission reduction, not only rotation.

Technical breakdown

How exposed AWS keys create direct cloud access

An AWS access key pair is a bearer credential. If it appears in public JavaScript or another client-side artifact, anyone who finds it can use it unless scope, policy, or revocation blocks the path. The issue is not the key format alone, but the fact that the key becomes a usable identity with the permissions attached to it. In cloud environments, that can mean S3 enumeration, object reads, or even writes if the policy is mis-scoped. Because the request looks like normal API traffic from a valid identity, network controls often do not flag it immediately.

Practical implication: move exposed credentials out of client-facing code and enforce least privilege on every key that remains active.

Why client-side encrypted secrets are still exposed secrets

Client-side encryption does not help if the decryption logic and ciphertext are shipped together in the browser. In that pattern, the user receives everything needed to recover the secret locally, so the browser becomes the disclosure point rather than the protection layer. This is a common failure mode in web apps that try to hide access material in front-end bundles while still relying on it for backend or integration access. From an identity perspective, it converts a supposedly controlled credential into a recoverable token with weak or no meaningful secrecy.

Practical implication: keep credentials server-side or replace them with short-lived, scoped tokens that cannot be reconstructed from client code.

How trusted tokens and third-party API keys widen blast radius

Trusted tokens, API keys, and partner integrations can create broad access when they authenticate with minimal context. In the Tata Motors case, a token mechanism allowed account impersonation with only a username and site name, which removed a critical proof step. Third-party API keys added another exposure path because the security of the main platform was only as strong as the weakest integration. This is where secrets management and identity governance meet: every integration token needs explicit lifecycle ownership, scoping, logging, and revocation. Without that, the identity surface keeps expanding invisibly.

Practical implication: inventory every integration token and require lifecycle ownership, logging, and automatic revocation for partner access.

Threat narrative

Attacker objective: The objective is to turn exposed secrets into authorised-looking access that bypasses perimeter controls and reveals sensitive cloud and analytics data.

1. Entry occurred when attackers or observers could recover AWS keys and API tokens from public web assets and client-side code.
2. Escalation followed because those credentials carried broad S3 and analytics access, allowing impersonation and large-scale data enumeration.
3. Impact came from exposure of telemetry, invoices, dashboards, and other sensitive records across connected systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static secrets are still the most dangerous identity shortcut in cloud environments. When AWS keys and API tokens live in browser code or other public artifacts, they stop behaving like controlled credentials and start behaving like reusable access material. That is why exposed secrets remain a primary cloud entry point even when perimeter controls are intact. Practitioners should treat any externally reachable secret as a governance failure, not just a leakage event.

Client-side secret handling is an identity design flaw, not a coding mistake. The assumption behind front-end embedded keys is that the browser can be trusted to hold what should have been server-side only. That assumption fails because every user receives the same secret-bearing bundle, which makes recovery trivial. The implication is that identity programmes must stop treating client-side exposure as an implementation detail and start treating it as an access model defect.

Token scope determines blast radius more than token format does. A trusted token that can impersonate an account without strong proof of identity is a privileged control failure, even if the token is technically temporary. Broad S3 permissions, weak analytics impersonation, and partner API keys all demonstrate the same pattern: the access object is only as safe as the scope attached to it. Practitioners should classify every token by the data and actions it can reach, then govern that scope as tightly as a privileged account.

Unified identity monitoring is now a cloud exposure control, not just a detective control. The important shift is that secret discovery, permission analysis, and anomalous usage need to be correlated as one workflow. Isolated scanners can find leaked keys, but they cannot by themselves show whether those keys are already active or already over-scoped. Identity security teams should therefore treat exposed-secret telemetry as part of operational access governance, not a separate hygiene stream.

Ephemeral credential trust debt: Exposed secrets create a long tail of risk because revocation often lags exposure, and every hour of delay extends the usable attack window. That pattern is what makes secrets sprawl so hard to contain in large cloud estates. Practitioners should assume the exposure clock starts at disclosure, not at incident triage.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• Use the Guide to the Secret Sprawl Challenge to map where secrets leak, how they persist, and which controls shrink exposure windows fastest.

What this signals

The operational lesson is that secret discovery without revocation is incomplete governance. When a leaked key can remain usable long after exposure, the programme needs a control loop that joins detection, ownership, and action in minutes rather than days.

Identity blast radius: the real unit of risk is no longer the secret itself but the set of systems that secret can reach. Teams that can measure blast radius by token and integration will have a much clearer view of where to prioritise remediation. For a broader control baseline, anchor the work in the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10.

Public cloud estates and SaaS integrations now need the same governance discipline traditionally reserved for privileged human accounts. The practical shift is to treat every exposed token as a lifecycle event, not just a security alert, and close the loop through inventory, review, and automated revocation.

For practitioners

• Remove credentials from client-facing assets Scan JavaScript bundles, SPAs, mobile packages, and public repos for embedded keys, then refactor any credential use to server-side calls or brokered tokens. Treat any recoverable secret in front-end code as already exposed.
• Scope every remaining key to the smallest reachable resource set Review AWS, analytics, and partner tokens for bucket-level, account-level, and impersonation rights that exceed their intended job function. Replace broad access with narrowly scoped roles and explicit deny rules where feasible.
• Automate detection of exposed-secret activity Alert on key IDs appearing in public code, first-seen access after long dormancy, unusual ListBucket or GetCallerIdentity calls, and token issuance without expected authentication checkpoints. Link those signals to revocation workflow in the same control plane.
• Require lifecycle ownership for third-party integration tokens Assign a named owner for every API key and trusted token, then enforce logging, periodic review, and sunset dates for partner access. If no owner exists, the token should be treated as ungoverned access.

Key takeaways

• Exposed cloud keys and browser-shipped tokens turn ordinary deployment mistakes into direct identity exposures.
• The evidence points to broad blast radius, with more than 70 TB of data reachable through a small number of leaked credentials.
• Fast revocation, least privilege, and client-side secret removal are the controls that materially reduce this risk.

Key terms

• Static Secret: A static secret is a long-lived credential such as an API key, token, or access key that does not expire quickly. In cloud and SaaS environments it becomes high risk because exposure can create repeated access until the secret is revoked or rotated.
• Client-Side Credential Exposure: Client-side credential exposure happens when a secret is embedded in code delivered to the browser or app package. The user can recover it locally, which means the secret is no longer protected by a server-side trust boundary.
• Blast Radius: Blast radius is the amount of data, systems, or actions an identity can reach if it is misused. In NHI governance, it is the practical measure of how far a leaked key, token, or account can move before containment succeeds.
• Trusted Token: A trusted token is a credential or session artifact that grants access based on limited input or a lightweight proof step. When poorly scoped, it can enable impersonation, overreach, or silent access to analytics and business systems.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step breakdown of the exposed AWS key paths in the E-Dukaan and FleetEdge assets
• The specific token handling weaknesses behind the Tableau impersonation flow and Azuga API exposure
• The monitoring signals Unosecur recommends for spotting dormant keys that suddenly become active
• The remediation sequence Unosecur describes for rotating and scoping compromised credentials

👉 The full Unosecur post covers the Tata Motors exposure paths, signal patterns, and remediation steps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.