How do application security and IAM teams share responsibility for exposed code?

Why This Matters for Security Teams

Exposed code creates a shared risk surface because application security and IAM are often protecting different parts of the same trust chain. Application security focuses on whether the code can be tampered with, replayed, or reverse engineered into bypassing intended controls. IAM focuses on whether an exposed client can still be trusted to make authentication or authorisation decisions. The problem is not merely code visibility, but where security logic is enforced and whether that logic can be shifted to a more trusted layer.

This matters most when mobile apps, desktop clients, browser front ends, or embedded agents carry logic that should have lived on the server. If a secret, token, policy check, or decision path is embedded in exposed code, attackers can inspect it, alter it, or use it to map the control plane. That is exactly the kind of boundary weakness highlighted in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access enforcement and system integrity are expected to be handled through stronger control layers.

For NHI programs, the same issue appears when an app or agent carries embedded credentials or makes token-handling decisions locally. In practice, many security teams encounter the flaw only after a reverse-engineered client has already revealed how authz, secrets, or feature gates were being enforced, rather than through intentional design review.

How It Works in Practice

Shared responsibility works best when the division is explicit. Application security should define what must never be trusted in exposed code, while IAM should define what must never be decided there. That means removing static secrets from clients, avoiding client-side authorisation decisions, validating tokens server-side, and ensuring that session, device, and privilege decisions are anchored in the back end rather than in the user interface.

In a mature workflow, both teams review the same attack paths but from different angles:

• Application security tests whether exposed code can be decompiled, modified, or instrumented to bypass controls.
• IAM verifies that authentication, token lifecycle, and privilege decisions remain authoritative even if the client is hostile.
• Both teams confirm that secrets, API keys, signing material, and policy assertions are not hardcoded or cached in ways that can be replayed.
• Both teams define where step-up authentication, conditional access, and session revocation are enforced.

That division becomes especially important in agentic systems and API-heavy applications, where the client may include automation logic, bearer tokens, or tool invocation paths. The Anthropic report on an Anthropic — first AI-orchestrated cyber espionage campaign report is a useful reminder that automation can scale abuse quickly when trust boundaries are weak. For identity-heavy systems, the same design principle applies: the client can initiate a request, but it should not be the source of truth for trust.

Operationally, the cleanest pattern is to treat exposed code as observable and potentially adversarial. Security checks should be replicated or validated server-side, and any code path that depends on a secret or privilege assertion should be assumed recoverable by an attacker. These controls tend to break down in thick-client, offline-first, or legacy single-page applications because the business logic is forced into the client and cannot be cleanly re-centralised.

Common Variations and Edge Cases

Tighter control over exposed code often increases delivery friction, requiring teams to balance user experience, offline support, and release velocity against stronger trust boundaries. Current guidance suggests that the more logic a client carries, the more aggressively it should be treated as untrusted, but there is no universal standard for how much logic is acceptable in every environment.

Some applications can tolerate minimal client-side logic because the client only renders data and submits requests. Others, such as desktop tools, mobile apps, or edge-connected software, may need local decision-making for usability or resilience. In those cases, the decision should still be validated centrally, and any local enforcement should be assumed advisory rather than authoritative.

IAM teams also need to account for edge cases where exposed code interacts with delegated access, service tokens, or short-lived credentials. If the application is issuing or storing secrets on behalf of users or non-human identities, then application security and IAM must jointly define rotation, revocation, and proof-of-possession expectations. That intersection is often missed when teams assume the front end can safely "own" parts of the control flow. The practical test is simple: if reversing the code would reveal how trust is granted, the design needs rework.

Related resources from NHI Mgmt Group

• How should security and IAM teams share responsibility for in-person identity checks?
• How do IAM and platform teams share responsibility for API security?
• How should security teams respond when a secret is exposed in code or logs?
• How should security teams handle secrets found in application code?