SnowFROC 2026 shows why NHI governance must move into the workflow

At a glance

What this is: SnowFROC 2026 highlighted how secure defaults, trust boundaries, and workflow-level controls are becoming central to AppSec and NHI governance.

Why it matters: For IAM and NHI practitioners, the event reinforces that credentials, tokens, and agentic workflows must be governed where they are created and used, not after the fact.

By the numbers:

• The conference drew about 400 attendees to see 35 sessions, take part in 8 half-day training sessions, a CTF, and multiple village activities.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read GitGuardian's SnowFROC 2026 analysis of AppSec, AI, and trust boundaries

Context

Modern software teams now build with AI assistance, shared packages, and automation that depends on non-human identities. That combination creates a governance gap because tokens, service accounts, and build credentials often outlive the decisions they were meant to support, while security review still happens too late in the workflow.

SnowFROC 2026 used developer behaviour, supply chain trust, and machine-driven delivery to show that NHI governance is no longer a separate identity problem. It is becoming part of how engineering systems are designed, and the event’s emphasis on defaults, feedback loops, and contextual controls is typical of where the field is heading.

Key questions

Q: How should security teams govern non-human identities in AI-assisted development?

A: Start by treating every automation account, token, and build credential as a governed identity with ownership, scope, expiry, and revocation. Then place controls in the editor, CI system, and approval workflow so risky actions are checked before execution. Governance that arrives after deployment is too late for fast-moving delivery pipelines.

Q: Why do AI-assisted pipelines increase the risk of secrets exposure?

A: AI-assisted pipelines create more places for secrets to appear, including prompts, generated code, copied snippets, and automated workflows. They also increase automation bias, which makes developers more likely to accept unsafe suggestions or skip validation. The result is a larger exposure surface and weaker human friction at the point of decision.

Q: What is the difference between static policy and runtime NHI governance?

A: Static policy defines what should happen, while runtime governance controls what actually happens when a secret, token, or service account is used. Runtime controls matter more because attackers exploit live permissions and active trust relationships. In practice, the stronger programme combines policy with execution-time enforcement and fast revocation.

Q: How can organisations reduce trust sprawl in software delivery?

A: Reduce trust sprawl by inventorying every delegated identity, removing unnecessary standing access, and shortening the lifetime of credentials that support builds, releases, and integrations. Pair that with attestation, least privilege, and regular review of who or what can act on behalf of the pipeline. Trust sprawl shrinks when identity ownership is explicit.

Technical breakdown

Why borrowed trust is now the dominant attack surface

Borrowed trust means a system relies on identities, packages, maintainers, runners, or automation that it did not directly create and does not fully control. In modern AppSec, that shows up in dependency installs, CI tokens, GitHub Actions secrets, browser extensions, and AI-generated code paths. The failure mode is not only credential theft. It is that teams accept trust relationships as a convenience layer and then discover they have created high-value paths for abuse. Once an attacker gains a trusted identity, they often inherit the system’s own permissions and delivery reach. That is why non-human identity governance now needs inventory, scoping, monitoring, and rapid revocation built into the same operational model as code delivery.

Practical implication: Treat every trusted automation path as a governed identity with ownership, scope, and revocation requirements.

How AI-assisted development changes secrets and workflow risk

AI-assisted development increases output, but it also increases the number of places where secrets, tokens, and unsafe patterns can appear. Code is now created in prompts, assistant outputs, shared snippets, and non-IDE workflows, which means security controls that only inspect final commits will miss a lot of exposure. The deeper issue is automation bias. Developers are more likely to accept confident suggestions, copy unsafe code, or skip validation when the path is fast and the feedback is weak. That shifts the security burden from inspection alone to prevention, contextual warnings, and secure defaults in the tools people actually use.

Practical implication: Put controls in the prompt, editor, and pull request flow so unsafe patterns are blocked before they become durable secrets exposure.

What layered AppSec means for NHI governance

Layered AppSec is not about more tools for their own sake. It is about placing the right control at the moment a risky decision is made. In NHI terms, that means short-lived credentials, scoped access, attestation, rotation, and continuous review should all be connected to the workflow that issues or uses the identity. The strongest sessions at the conference pointed to the same architecture: reduce standing trust, shorten exposure windows, and collect feedback from real usage rather than assuming policy alone changes behaviour. For NHI governance, that is the difference between a policy document and an operating model.

Practical implication: Map each NHI control to the workflow stage where the identity is created, used, or approved.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Secure defaults are now an NHI control pattern, not just a developer-experience preference. When people operate under deadline pressure, they choose the easiest path. That is why identity governance has to move from annual review and policy documents into the tools that issue secrets, approve access, and surface warnings. If the safer path is not the default path, the organisation has already accepted unnecessary identity risk.

Borrows trust: the new NHI governance debt lives in automation and supply chains. Tokens, runners, package trust, and service accounts are all forms of delegated authority. Once that authority is spread across build systems and AI tooling, the blast radius is governed less by perimeter controls and more by how precisely each identity is scoped, rotated, and revoked. Practitioners should treat trust sprawl as a measurable debt item.

Runtime governance gap: the field still over-invests in static policy while under-investing in controls that fire at execution time. That gap matters because attackers do not wait for governance reviews. They exploit the live identity path, where permissions are already active and where automation can amplify a small compromise into broad reach. Teams should align controls to runtime, not just compliance checkpoints.

Behavioural security is becoming identity security. The event’s strongest theme was that insecure outcomes often follow predictable human patterns: haste, overconfidence, and habit. In NHI governance, that means the technical control set must be paired with nudges, guardrails, and measurable feedback loops. The practical conclusion is simple: design identity systems that make the secure choice the easy choice.

AI-assisted software production will force identity teams to own more of the delivery pipeline. As code creation moves outside the traditional IDE and becomes more agent-assisted, the identity layer expands into prompts, workflows, and machine-to-machine approvals. That broadens the governance surface but also creates an opportunity to standardise detection, scoping, and accountability earlier. Practitioners should prepare for identity controls to become a development-platform concern.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• If you need a deeper baseline on lifecycle controls, the State of Secrets in AppSec also shows how budget allocation and remediation lag shape real-world exposure.

What this signals

The programme signal is clear: NHI governance has to be embedded into delivery systems, not layered on top of them after the fact. As AI-assisted production expands, teams will need stronger ownership models for service accounts, tokens, and machine-issued credentials, plus better measurement of where those identities actually act.

Identity blast radius: the practical unit of risk is no longer a single leaked token, but the reach that token has across automation, CI, and downstream services. That is why teams should align with NIST Cybersecurity Framework 2.0 for governance, identification, protection, detection, response, and recovery, while using DeepSeek breach lessons to stress-test where trust assumptions fail.

With 43% of security professionals concerned that AI systems may learn and reproduce sensitive information patterns from codebases, the next governance step is broader than secret rotation. Security teams should prepare for prompt hygiene, contextual review, and tighter controls around where machine-generated output can re-enter trusted repositories.

For practitioners

• Move identity controls into the workflow Place approval, warning, and revocation logic where secrets are issued and used, including CI, IDE extensions, and automation runners. Controls that only run at audit time will miss the decision point that creates the risk.
• Inventory delegated trust paths Document every service account, token, package trust relationship, and automation identity that can act on behalf of a developer or platform. Include ownership, scope, expiration, and the systems each identity can reach.
• Shorten credential lifetime aggressively Prefer ephemeral access for build systems, agents, and integration accounts, then force rotation and revocation processes that can be executed quickly. Long-lived tokens turn minor compromise into persistent access.
• Measure secure defaults adoption Track whether developers actually use secure templates, pre-commit checks, and policy-enforced controls. If adoption is low, the issue is operational design, not awareness.
• Tie AI review to real vulnerability data Evaluate assistant prompts, rule changes, and review automation against historical defects and known anti-patterns. That keeps the programme focused on reduction of real risk instead of model confidence.

Key takeaways

• Security teams cannot govern non-human identities effectively if identity controls still arrive after code and automation decisions are already made.
• The conference reinforced that borrowed trust, not just code flaws, is now a primary route into delivery systems and machine credentials.
• Practitioners should shift from policy-only programs to runtime controls, shorter credential lifetimes, and measurable workflow adoption.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity that acts without a person directly driving each action, including service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. These identities often carry broad delegated authority, which makes ownership, scoping, lifecycle control, and revocation central to risk reduction.
• Borrowed Trust: Borrowed trust is the security condition where one system relies on another system, package, token, or automation path to act legitimately on its behalf. In practice, it creates hidden attack paths because the trusted component often inherits permissions broader than the original use case requires.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised credential, token, or service account can cause before it is detected and revoked. It depends on privilege scope, credential lifetime, downstream reach, and how quickly an organisation can cut off the identity when misuse begins.
• Runtime Governance: Runtime governance is control enforcement at the moment an identity is used, not just when policy is written or reviewed. It matters for NHI security because attackers exploit active permissions and automation paths, so the decisive control is the one that can verify, restrict, or revoke access in motion.

What's in the full article

GitGuardian's full post covers the session-level operational detail this post intentionally leaves for the source:

• Speaker-specific notes from Tanya Janca, Chris Lindsey, Jenn Gile, and Mudita Khurana that show how each team operationalises the control patterns.
• Conference observations on developer workflow friction, security champion design, and how AI changes review practices in real engineering teams.
• Examples of secure-default tooling, package scrutiny, and credential-handling habits that were discussed in the sessions.
• The practical lessons from hallway conversations and cross-team implementation tradeoffs that do not fit into a conference summary.

👉 The full GitGuardian post includes the session notes, speaker takeaways, and conference-specific observations.

Deepen your knowledge

NHI governance, secrets lifecycle controls, and trust-boundary design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI-assisted delivery and machine identities, it is worth exploring.