Identity policy must move from logging in to controlling risk

At a glance

What this is: This analysis argues that identity policy must become the control point for access decisions, because valid tokens and reused credentials now bypass perimeter-style assumptions.

Why it matters: IAM teams need to treat sign-in as a risk decision, not a binary authentication event, especially where NHI, agent access, and high-value business systems intersect.

By the numbers:

• 70% of security incidents it investigated last year, st year were identity-related weaknesses.
• In August 2025, one attacker group stole OAuth tokens from a single trusted integration and walked into the Salesforce environments of more than 700 organizations.
• In 2024, attackers walked into the data warehouses of about 165 companies just by reusing stolen passwords.

👉 Read Newcore's analysis of security-first access policy for identity control

Context

Identity policy is the decision layer that should determine whether access is allowed, stepped up, or denied based on the value and context of the target system. The article’s core point is that current controls often authenticate the identity but fail to govern the risk of what that identity can reach, which is where NHI, human IAM, and agent access all converge.

That gap matters because valid credentials now behave like open doors when the trust model is too static. When tokens, passwords, or delegated integrations are accepted without enough context, the identity programme becomes a logging system instead of a control system, and the blast radius expands across SaaS, cloud, and internal data platforms.

Key questions

Q: How should security teams handle trusted OAuth integrations that can reach critical systems?

A: Treat every trusted integration as a standing access path that needs its own lifecycle, scope review, and revocation criteria. If an OAuth app can reach a sensitive workload, its permissions should be justified as if it were a privileged account, because it can become a silent entry point when tokens are stolen or over-scoped.

Q: Why do valid credentials remain such a major enterprise risk?

A: Valid credentials work because they bypass many traditional perimeter controls and often inherit legitimate access. Once stolen, they can be used from normal login flows, especially where MFA is weak, incomplete, or excluded. That is why identity security has to focus on assurance strength, not just login success, and on reducing how far a compromised identity can move once inside.

Q: What do organisations get wrong about posture tools and access policy?

A: They confuse detection with enforcement. Posture tools can identify weak settings and risky accounts, but they do not sit in the authentication path. Real risk reduction happens only when the identity platform can decide, in real time, whether to allow, step up, or block access.

Q: How should teams decide when to require stronger authentication for an application?

A: Base the requirement on the value of the application and the power of the role, not on a generic enterprise standard. Admin access to a customer system, ledger, or policy engine should face stronger proof than low-risk read-only access, because the same login has very different consequences.

Technical breakdown

Why valid tokens bypass traditional identity controls

A token, API key, or OAuth grant is already authenticated material, so the access layer often treats it as trustworthy until expiry or revocation. That works only if the system assumes the credential still belongs to the intended actor and that the actor’s risk profile has not changed. In practice, delegated access through trusted integrations creates a hidden trust chain: if the token is stolen or over-scoped, the platform may still honour it without challenge. This is why identity compromise increasingly looks like normal traffic rather than an intrusion event.

Practical implication: move sensitive integrations into continuous context checks and shorten the window in which a valid token remains sufficient.

How context-aware access policy differs from posture reporting

Posture tools can identify weak settings, such as missing MFA or over-permissioned accounts, but they sit beside the identity provider and do not decide access in real time. A context-aware policy engine evaluates who is signing in, what they are reaching, the sensitivity of the resource, the device state, and the current risk level before granting access. That changes the control from inspection to intervention. The article’s comparison to pipeline gates is useful: the highest-value control is the one that blocks unsafe action before it reaches the system of record.

Practical implication: place enforcement inside the sign-in path, not in a separate reporting layer that only creates cleanup work.

Why app and privilege criticality must shape authentication strength

Not every login should require the same proof. A read-only user reaching a low-sensitivity workspace does not present the same risk as an admin exporting customer records or changing access rules. NIST’s authentication assurance model already reflects this by grading authenticators from weaker to stronger forms. The missing step is to bind that assurance level to the business worth of the application and privilege being requested, so the policy can ask for phishing-resistant proof where the impact justifies it.

Practical implication: map application criticality and admin privilege to stronger authentication requirements instead of applying one uniform factor everywhere.

Threat narrative

Attacker objective: The attacker wants to turn trusted identity pathways into silent, scalable access to high-value business data without triggering conventional intrusion controls.

1. Entry via a trusted OAuth integration or reused password gives the attacker a legitimate-looking credential that the platform accepts without challenge.
2. Escalation follows when that credential carries enough scope or privilege to move from the original integration into connected business systems and data stores.
3. Impact occurs when the attacker operates through valid sessions, avoids MFA prompts, and extracts data or reconfigures access at scale.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

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

NHI Mgmt Group analysis

Identity policy is now the control plane, not an adjacent control. The article is right that posture reporting alone cannot stop misuse once a token or password is accepted. The field needs to stop treating identity policy as a settings layer and start treating it as the enforcement point where access, risk, and business context intersect. Practitioners should frame every identity decision around where enforcement actually happens.

Trusted integration risk is a governance problem, not just a credential problem. OAuth tokens, delegated SaaS connections, and service access often inherit trust from the platform that issued them, not from the current state of the relationship. That means the real failure is not merely exposure, but unchallenged transitive trust across systems. Security teams should review every integration that can become a hidden pathway into core business applications.

Adaptive proof requirements are the missing bridge between IAM and business criticality. The article’s point about stronger authenticators for higher-value access is sound, but the deeper issue is that many programmes still assign proof strength before they understand the workload or privilege impact. Identity governance should therefore link assurance to application worth and privilege tier, or else the same credential standard will protect a meeting room and a customer ledger equally.

Context-aware access policy creates a new named gap: identity decision drift. This is the condition where the policy decision no longer reflects the current sensitivity of the target, the privilege requested, or the trustworthiness of the session. It happens when tags are set once and then left to decay while business value changes. Practitioners should treat stale access decisions as a governance defect, not an optimisation issue.

The practical challenge is balancing friction against blast radius. The article correctly notes that every control that reduces attack surface also adds friction for legitimate users and agents. The governance task is not to minimise friction everywhere, but to concentrate it where the business impact justifies it. IAM teams should use that principle to decide where step-up proof, conditional access, and session termination belong.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap reinforces why lifecycle visibility and access governance need to extend beyond human IAM into machine and integration identities, as covered in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Identity decision drift: when application sensitivity changes but access labels do not, policy becomes a stale approximation of risk rather than a live control. Teams should expect more incidents where the credential is valid but the authorisation decision is no longer fit for the system being reached.

The operational shift is toward proving access in context, not just authenticating a subject. That means IAM and PAM programmes will increasingly need to coordinate with workload and SaaS governance, especially where integrations can move from low-risk convenience to high-risk business dependency without a corresponding policy change.

For practitioners

• Map all trusted integrations that can reach crown-jewel systems Inventory OAuth apps, service connections, and delegated tools that can access finance, customer, or admin data. Remove any integration whose business purpose is unclear or whose owners cannot explain why it needs the current scope.
• Move access decisions into the identity provider path Use policy enforcement that can step up, deny, or terminate a session before the request reaches the target application. Separate that from posture reporting, which can flag risk but cannot stop it.
• Bind authentication strength to resource criticality Require phishing-resistant authenticators for high-impact applications and privileged roles rather than applying one factor level everywhere. Revisit labels such as crown jewel or high sensitivity whenever a system’s business function changes.
• Simulate policy changes against real users and roles Test new access rules against the actual population before enforcement so you can see who is blocked and who retains unsafe access. This is the cleanest way to find bad assumptions before they become incident response work.

Key takeaways

• The core risk is not failed authentication, but trusted identity pathways that still grant access when the underlying context has become unsafe.
• The evidence pattern is consistent: stolen tokens, reused passwords, and over-trusted integrations can reach sensitive systems at scale without tripping traditional alarms.
• Practitioners should move access policy into the sign-in path and tie proof strength to application criticality and privilege, not to identity alone.

Key terms

• Context-Aware Policy: Context-aware policy is a control model that decides access based on current conditions, not just preassigned entitlement. For AI agents and other non-human identities, this means privileges, tool use, and monitoring expectations can change as the task, environment, or risk signal changes.
• Trusted Integration: A third-party or internal connection that is already authorised to act on behalf of a user, service, or application. These integrations are powerful because they inherit trust from the platform, which is exactly why stolen or over-scoped tokens can cause broad downstream access.
• Application Criticality: The business value and sensitivity of the system being accessed, such as a finance ledger, customer database, or privileged admin console. It is a governance input that should influence authentication strength, authorisation logic, and session monitoring rather than being left as a static label.
• Identity Drift: Identity drift is the gap between the access path originally approved and the behavior that exists later. For browser extensions, drift can appear through updates, remote configuration, publisher changes, or permission expansion, turning a trusted integration into a materially different risk.

What's in the full article

Newcore's full article covers the operational detail this post intentionally leaves for the source:

• How the source article maps access policy to application worth and risk scoring in practice
• The comparison between identity policy enforcement and posture tools in the sign-in path
• Examples of stronger authenticator levels for higher-value access decisions
• The article's own explanation of secure split key infrastructure and device-bound synced passkeys

👉 Newcore's full post covers the policy mechanics, risk scoring logic, and access-path details behind the framework.

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 building or maturing an IAM, PAM, or identity governance programme, it is worth exploring.