TL;DR: NHI enrichment attaches ownership, dependencies, behavioral baselines, and credential relationships to non-human identities so teams can turn scattered logs and alerts into decisions, according to Oasis Security. The deeper shift is that blast radius, anomaly review, and remediation all depend on context that most identity programmes still do not have.

NHIMG editorial — based on content published by Oasis Security: Inside Oasis’s NHI Enrichment Layer, how context gets built

Questions worth separating out

Q: How should teams enrich non-human identities before rotating credentials?

A: Start by attaching ownership, consumers, downstream resources, and credential relationships to each identity.

Q: Why do non-human identities need behavioral baselines?

A: Because the same authentication event can be routine for one identity and suspicious for another.

Q: What breaks when ownership is missing for an NHI?

A: Lifecycle governance breaks first, because no one can confidently approve rotation, offboarding, or recertification.

Practitioner guidance

• Map every production NHI to an accountable owner Require an application, team, or vendor owner for each service principal, API key, token, or certificate before it is allowed to remain in production.
• Build dependency-aware rotation runbooks Document which applications, workflows, and consumers will fail if a secret changes, then test rotation against that dependency map before shortening credential lifetimes.
• Baseline identity behavior by consumer group Define normal activity using the identity's own source network, geography, credential type, and access pattern.

What's in the full article

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

• The live graph model showing how consumers, resources, and secrets are linked for each identity
• The specific integration sources Oasis uses to deepen ownership, dependency, and sensitivity context
• The behavioral baseline logic used to flag new consumer groups and unusual credential patterns
• The timeline view that ties identity-provider changes to remediation and ownership updates

👉 Read Oasis Security's analysis of NHI enrichment and identity context →

NHI enrichment layers: what context teams still lack in practice?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Enterprises are now running five to ten secret stores at once, and the vendor argues that vaulting alone cannot govern non-human identities because consumer context, ownership, and dependency-aware rotation sit outside any single vault's boundary. That makes multi-vault governance a structural IAM problem, not a storage problem.

NHIMG editorial — based on content published by Oasis Security: The Multi-Vault Reality of Modern PAM

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.

Questions worth separating out

Q: How should security teams govern secrets across multiple vaults?

A: Security teams should govern multi-vault environments above the storage layer.

Q: Why does single-vault consolidation often fail in enterprise identity programmes?

A: Single-vault consolidation often fails because cloud-native stores are deeply embedded in deployment workflows and enterprise PAM platforms add friction at machine-identity scale.

Q: What breaks when teams rotate secrets without mapping dependencies first?

A: Rotation without dependency mapping breaks applications because the team changes a credential before knowing which workloads rely on it.

Practitioner guidance

• Inventory secrets across every store Build a unified inventory that includes enterprise vaults, cloud-native secret managers, CI/CD stores, environment variables, and SaaS platform credentials.
• Map the consumer-to-resource chain before rotation Document which application, service, or pipeline consumes each secret, what identity it authenticates as, and which resource it reaches.
• Apply one rotation and expiry policy across all vaults Set a single standard for rotation cadence, ownership approval, and expiration limits, then enforce it in every secret store.

What's in the full article

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

• How the governance layer maps the consumer-to-resource context chain across AWS Secrets Manager, Azure Key Vault, CyberArk, Delinea, and HashiCorp Vault
• Why consolidation usually fails because cloud integration, licensing friction, and developer workflow choices preserve secret sprawl
• What safe dependency-aware rotation looks like when multiple applications and pipelines share the same secret
• How the vendor positions its architecture alongside existing PAM and vault investments

👉 Read Oasis Security's analysis of multi-vault PAM and NHI governance →

Multi-vault PAM sprawl: what IAM teams need to do now?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Static credentials remain a persistent breach path in cloud and hybrid environments, with IBM data cited in the source showing they contributed to over 60% of cloud-related breaches and averaged $4.81 million in losses with 292 days to contain. The governance shift is clear: dynamic, policy-driven authentication should become the default while legacy secrets are steadily shrunk, not simply rotated.

NHIMG editorial — based on content published by Oasis Security: Govern the Mix: Static and Federated Non-Human Identities

By the numbers:

• 61% of organizations have secrets, like cloud credentials, exposed in public repositories.

Questions worth separating out

Q: How should security teams manage a mix of static secrets and federated workload identities?

A: Treat them as one governed estate with different control requirements.

Q: Why do static service accounts create so much breach risk in cloud environments?

A: Because they persist until someone revokes them, and that persistence gives attackers a reusable foothold.

Q: What breaks when organisations try to govern non-human identities without lifecycle ownership?

A: Credentials linger after the business need has ended, permissions drift away from their original purpose, and revocation becomes slow or incomplete.

Practitioner guidance

• Audit every long-lived secret for ownership and expiry Build a living inventory of API keys, access tokens, and service passwords with a named owner, business purpose, environment, and planned retirement date.
• Move eligible workloads to federated issuance first Start with services that already run in supported clouds or clusters and replace copied secrets with managed workload identities, SPIFFE/SPIRE-based identities, or IdP-backed federation where the integration is mature.
• Enforce rotation as a containment control, not a final state Set maximum age limits, monitor first-use after rotation, and require service-side rollback plans so rotation shortens exposure instead of becoming a compliance ritual.

What's in the full article

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

• A dependency-aware migration approach for moving from static credentials to federated identities without breaking service connections
• Practical guidance for handling vendor APIs, legacy systems, and cross-org workflows that cannot yet abandon static secrets
• Operational steps for vaulting, ownership assignment, rotation, and revocation when static credentials must remain in use
• Examples of policy-based lifecycle orchestration across clouds, clusters, and runtimes

👉 Read Oasis Security's analysis of static and federated non-human identity governance →

Static credentials and federated NHI governance: what changes now?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Secret scanners can now find exposed API keys and tokens quickly, but most organisations still stall on remediation because the alert does not reveal whether a secret is live, what it can reach, or how to retire it safely, according to Oasis Security. The real control gap is identity context, not detection speed.

NHIMG editorial — based on content published by Oasis Security: Identity-aware secret scanning: From “Found” to “Fixed”

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

Questions worth separating out

Q: How should security teams handle exposed secrets without breaking production?

A: Security teams should first map the secret to its owning non-human identity, then confirm whether it is live, what it can access, and whether dependent systems can tolerate revocation.

Q: Why do leaked API keys and tokens remain a governance problem after detection?

A: Detection only proves that a secret exists in a risky place.

Q: What do organisations get wrong about secret rotation in NHI programmes?

A: They often treat rotation as a universal fix, even when they cannot confirm which systems depend on the credential.

Practitioner guidance

• Map exposed secrets to owning identities Link every scanner finding to the service account, API key, token, or certificate that actually uses it.
• Require blast-radius checks before revocation Verify what the credential can access, which production systems depend on it, and whether the secret is still live before disabling it.
• Build a safe rotation path for live credentials Use a rotation workflow that updates consumers, validates application health, and retires the old secret only after the new one is confirmed.

What's in the full article

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

• The step-by-step flow from raw scanner alert to identity correlation and safe remediation.
• The specific ownership and usage data fields needed to determine whether a secret is live.
• The example remediation path for a credential embedded in a Teams message or similar collaboration tool.
• The practical differences between immediate revocation and orchestrated rotation for active production identities.

👉 Read Oasis Security's analysis of identity-aware secret scanning and remediation →

Identity-aware secret scanning: what teams need to fix faster?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: A CVSS 9.7 flaw in Cline’s local kanban server let any website connect cross-origin, stream workspace data, inject terminal commands, and disrupt tasks, exposing developer environments and AI agent sessions to silent browser-based abuse, according to Oasis Security. The issue shows why agent-facing local services need origin checks, authentication, and tighter runtime policy.

NHIMG editorial — based on content published by Oasis Security: Cross-Origin WebSocket Hijack in Cline's Kanban Server

Questions worth separating out

Q: What breaks when a local AI agent service accepts browser connections from any website?

A: The trust boundary collapses because the browser becomes an untrusted transport into a privileged local control plane.

Q: Why do AI coding agents create a bigger access risk than ordinary developer tools?

A: They often combine source code access, terminal execution, repository context, and cloud credentials in one runtime.

Q: What do security teams get wrong about WebSocket-based local services?

A: They assume browser protections that apply to normal web requests also protect persistent local WebSocket channels.

Practitioner guidance

• Inventory every browser-reachable local agent service Identify developer tools that open localhost listeners for AI agent sessions, then verify whether they enforce origin checks, client authentication, and process-level binding restrictions.
• Split telemetry from command channels Keep read-only workspace sync separate from terminal input or task-control channels so an untrusted caller cannot turn observation into execution.
• Require explicit trust for terminal-bearing paths Gate any terminal input or task termination action behind a separate authorization step, even when the caller is on the same host.

What's in the full report

Oasis Security's full research covers the operational detail this post intentionally leaves for the source:

• Packet-level description of the vulnerable localhost WebSocket flow and how the browser reached it.
• Proof-of-concept command injection and task-termination behaviour that shows the control-plane impact.
• Patch context for version 0.1.66 and the specific checks the vendor added in response.
• Technical notes on why browser same-origin expectations do not protect this local listener.

👉 Read Oasis Security's analysis of the Cline cross-origin WebSocket hijack →

Cline WebSocket hijack: what it means for AI agent governance?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: As AI agents spread across SaaS, cloud, and internal services, organisations are struggling to discover what identities they use, what data they touch, and who owns them, according to Oasis Security. The core issue is no longer model access but identity visibility and lifecycle control across agent-driven actions.

NHIMG editorial — based on content published by Oasis Security: How to discover, map, and secure AI Identities

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: How should security teams inventory AI agents before granting production access?

A: Start by building a register that links each agent to its owner, the identities it uses, the systems it can reach, and the data it can touch.

Q: Why do AI agents create more identity risk than traditional automation?

A: Because agents combine access, decision-making, and tool use in ways that can expand scope during runtime.

Q: What breaks when AI agents have no clear owner?

A: Lifecycle control breaks first, followed by revocation, review, and accountability.

Practitioner guidance

• Inventory every AI agent and its identities Build a live register of agents, the tokens or service accounts they use, the systems they can reach, and the business owner responsible for each one.
• Link agent ownership to lifecycle control Require named accountability for creation, scope changes, exceptions, and decommissioning so agent identities do not persist after the use case changes.
• Score agent risk from actual access paths Assess each agent by what data it touches, which permissions it inherits, and whether its behaviour matches approved use.

What's in the full article

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

• How Oasis models discovery across SaaS, cloud, local deployments, and the NHIs those agents leverage
• The seven-pillar access-management framework, including ownership attribution, credential hygiene, and threat detection
• Examples of the dynamic risk scoring logic used to surface anomalous or high-risk agent behaviour
• The platform's account of how vendor trust monitoring and continuous risk improvement fit into AI lifecycle governance

👉 Read Oasis Security's analysis of how to discover and secure AI identities →

AI identities and ownership gaps: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: A flaw in VS Code's MCP install dialog let a single click hide environment variables and headers, enabling remote code execution or silent session hijacking for AI tooling, according to Oasis Security's research. The issue shows that AI agent governance fails when install-time trust is assumed but never truly inspected.

NHIMG editorial — based on content published by Oasis Security: Envade: One Click in VS Code, Full Shell for the Attacker

Questions worth separating out

Q: What breaks when MCP install dialogs hide runtime settings?

A: The approval step breaks because the user is reviewing an incomplete trust boundary.

Q: Why do hidden MCP credentials and headers matter so much?

A: They matter because they can change which identity a tool uses after installation.

Q: How should security teams govern AI tools that write into workspace settings?

A: Treat every workspace-held setting that affects authentication, startup behaviour, or remote access as a governed identity artefact.

Practitioner guidance

• Audit persisted MCP configuration, not just install previews Review mcp.json files and any workspace-scoped settings for env, envFile, headers, cwd, and startup-loader values that were not intentionally entered.
• Block hidden credential injection paths in developer tooling Require install flows to render every persisted setting that can influence execution or authentication, including Authorization headers and environment variables.
• Inventory AI tooling as non-human identity surface Map which MCP servers, assistants, and extensions can access credentials, external APIs, or production systems, then assign owners and review cadence for each identity-bearing component.

What's in the full report

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

• The exact hidden settings pattern that allowed env and header values to survive the MCP install flow
• The proof-of-concept attack sequence showing how a crafted deeplink turns into local execution
• The specific configuration strings security teams should grep for in existing workspaces
• The MSRC disclosure timeline and the VS Code version that closes the flaw

👉 Read Oasis Security's analysis of the VS Code MCP install dialog flaw →

VS Code MCP install dialog flaw: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Three Claude.ai flaws that chained invisible prompt injection, file upload abuse, and an open redirect into silent data exfiltration from default sessions were found in Oasis Security’s Claudy Day research, with broader blast radius when integrations are enabled. The core failure is that AI agent governance still assumes prompts are what users intended, not attacker-shaped execution paths.

NHIMG editorial — based on content published by Oasis Security: Claudy Day: Chaining Prompt Injection and Data Exfiltration in Claude.ai

Questions worth separating out

Q: How should security teams govern AI assistants that can access files and APIs?

A: Treat each assistant as a non-human identity with explicit owners, least privilege, and a documented lifecycle.

Q: Why do AI assistants complicate zero trust and least privilege?

A: Because the assistant can combine context, memory, and tools at runtime in ways that are hard to fully enumerate at provisioning time.

Q: What do teams get wrong about prompt injection in AI assistants?

A: They treat it as a content safety issue instead of an access issue.

Practitioner guidance

• Inventory every AI assistant and connected integration Map each assistant, MCP server, API, file store, and browser entry point that can influence or extend a session.
• Strip hidden-input delivery paths from assistant entry points Block or sanitize pre-filled prompts, shared links, and any content that can carry invisible instructions into a chat session.
• Reduce sandbox egress to only required AI endpoints Limit the assistant’s ability to call upload or export APIs unless a business process explicitly requires them.

What's in the full report

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

• The exact URL parameter pattern and hidden HTML handling that made the prompt injection possible.
• The sandbox and Files API abuse path used to move extracted conversation content out of the session.
• The open redirect chain that let a trusted-looking domain deliver the payload through search.
• The responsible disclosure timeline and the remaining issues that were still being addressed at publication.

👉 Read Oasis Security's analysis of Claudy Day and Claude.ai prompt injection →

Claude.ai prompt injection and exfiltration: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: A website-to-local attack chain let researchers hijack OpenClaw, brute-force its localhost gateway password, auto-enrol a trusted device, and control a developer’s AI agent without user interaction, according to Oasis Security. The case shows why AI agent governance must assume local trust can be abused, not merely misplaced.

NHIMG editorial — based on content published by Oasis Security: OpenClaw Vulnerability: Website-to-Local Agent Takeover

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

Questions worth separating out

Q: What breaks when a local AI agent gateway trusts localhost too much?

A: A localhost trust model breaks when browser code can open a WebSocket to the local service and act as if it were a trusted client.

Q: Why do autonomous agents increase the blast radius of a browser-based attack?

A: Autonomous agents increase blast radius because one authenticated session can cascade into messages, logs, device access, and command execution across connected systems.

Q: What do security teams get wrong about local-only agent controls?

A: They often assume local-only means trusted-only, even though browsers can originate requests to localhost without user awareness.

Practitioner guidance

• Inventory local AI agents and gateways Map every developer workstation running an agent, local model server, or browser-reachable control plane.
• Remove trust from localhost pairing flows Require explicit user approval, step-up authentication, or a second channel before any new device becomes trusted.
• Throttle and log loopback authentication attempts Apply the same rate limits, lockouts, and audit logging to localhost as to remote access.

What's in the full report

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

• The full browser-to-local proof-of-concept flow, including the localhost WebSocket path and password-guessing mechanics.
• The exact gateway behaviour that exempted loopback traffic from rate limiting and device-pairing prompts.
• The version-specific remediation guidance for OpenClaw 2026.2.25 and later.
• The researcher-reported disclosure timeline and vendor fix response details.

👉 Read Oasis Security's analysis of the OpenClaw website-to-local agent takeover →

Website-to-local AI agent takeover: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: A flaw in Microsoft’s OneDrive File Picker can let connected web apps access a user’s entire OneDrive instead of only selected files, affecting hundreds of apps and potentially millions of users, according to Oasis Security. The issue exposes how vague consent, broad OAuth scopes, and token handling can turn routine file sharing into enterprise data exposure.

NHIMG editorial — based on content published by Oasis Security: OneDrive File Picker flaw provides ChatGPT and other web apps full read access to users’ entire OneDrive

Questions worth separating out

Q: What breaks when OneDrive integrations request broader access than the user action requires?

A: The access model stops matching user intent.

Q: Why do delegated web apps create governance risk for IAM teams?

A: Delegated web apps inherit access from the user but operate with their own token lifecycle, which makes them harder to review than direct human sessions.

Q: How do security teams know whether a file picker integration is too permissive?

A: Look for a mismatch between the user-facing task and the scopes requested.

Practitioner guidance

• Audit OneDrive delegated app consent paths Inventory every app that uses OneDrive File Picker and compare the granted scopes with the actual upload or download function.
• Remove refresh-token persistence from browser-based flows Eliminate code paths that store access tokens or refresh tokens in session storage or local storage.
• Treat delegated app access as part of access review Include enterprise applications using OneDrive in periodic access certification, not just human user reviews.

What's in the full analysis

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

• Step-by-step instructions for checking whether a private Microsoft account has already granted access to a vendor.
• Entra Admin Center navigation for reviewing enterprise applications, granted scopes, and the user who approved them.
• Specific mitigation advice for removing refresh tokens from browser-based flows and disposing of stored tokens securely.
• Practical alternatives such as using shared view-only links instead of OneDrive OAuth where the business process allows it.

👉 Read Oasis Security's analysis of the OneDrive File Picker scope flaw →

OneDrive File Picker access scope gap: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →