Non-engineer-led AI hackathons change internal tool delivery

At a glance

What this is: This is a WorkOS write-up on a one-day internal hackathon where 39 teams built AI-powered internal tools with a non-engineer in the driver’s seat.

Why it matters: It matters because faster self-service building increases the number of people and systems touching credentials, deployment paths, and internal data, which widens IAM and NHI governance scope.

By the numbers:

• 39 teams built AI-powered internal tools during Claude Day.

👉 Read WorkOS's Claude Day write-up on non-engineer-led AI building

Context

Non-engineer-led AI hackathons compress the path from idea to deployed internal tool, but they also shift identity risk outward into more hands, more accounts, and more lightly governed workflows. The primary question for IAM teams is not whether AI can help people build faster, but how access, secrets, and deployment authority stay controlled when building becomes self-serve.

In this case, WorkOS removed setup friction by pre-provisioning scaffolding, secrets, and deployment wiring so participants could start building immediately. That approach is typical of fast-moving internal developer programmes, and it is exactly where identity governance can lag behind productivity gains.

Key questions

Q: How should teams govern AI-assisted internal app building without slowing delivery?

A: Use time-bound access, named ownership, and explicit offboarding for every prototype identity. The goal is not to block self-service building, but to make sure secrets, deployment roles, and data access expire when the experiment ends or graduates into a managed service.

Q: Why do non-engineer-led build events increase identity risk?

A: Because they multiply the number of people who can trigger privileged workflows without increasing the number of people who understand the underlying access model. That usually expands token use, repository permissions, and cloud exposure faster than governance teams can review it.

Q: What breaks when AI-generated internal tools are left running after a hackathon?

A: The access model breaks first. Prototype apps often keep secrets, service accounts, and deployment permissions long after anyone remembers why they exist, which turns temporary convenience into unmanaged NHI sprawl.

Q: Who should own the cleanup of hackathon-created credentials and apps?

A: The team that created the app should own cleanup, with platform and security teams enforcing the process. If ownership is diffuse, the identities created for speed become orphaned credentials, and orphaned credentials are where governance usually fails.

Technical breakdown

Pre-provisioned scaffolding and the hidden identity boundary

The article describes a prebuilt CLI, example repos, GitHub Actions, secrets, and cloud wiring that let teams deploy from the first push. Technically, that means the identity boundary moved from provisioning time to execution time, because the environment was ready before participants touched it. In identity terms, the team changed the access model from “request then wait” to “start then operate,” which reduces friction but also reduces the natural checkpoints that usually force review of credentials, ownership, and blast radius.

Practical implication: map every preprovisioned build path to the identities, secrets, and repositories it implicitly authorises.

Non-engineer-driven tool creation and delegated access risk

When a less-technical teammate drives the work, the operating model becomes more like delegated identity management than traditional developer ownership. The article shows engineers were told to unblock rather than lead, while AI handled much of the mechanical work. That does not create autonomy in the strict identity sense, but it does create a broader set of people making runtime decisions about data access, code generation, and deployment sequencing. The governance problem is not the AI itself, but the widened circle of humans who can now trigger privileged workflows.

Practical implication: align repository, cloud, and secrets permissions to the smallest set of people who can actually change production-relevant behaviour.

AI-assisted internal apps and secret lifecycle discipline

The post notes that teams were given API keys, tokens, and access to internal systems so they could build Slack bots, dashboards, and workflow tools quickly. In NHI terms, that is a burst of short-lived but real credential issuance across many small projects. These credentials often outlive the hackathon unless there is a deliberate cleanup path, which is where identity governance breaks down in practice. The technical issue is not the initial grant. It is the lack of lifecycle controls that reclaim the access once the event is over and the prototype becomes abandoned code.

Practical implication: treat hackathon-issued secrets and service accounts as time-bound NHIs with explicit revocation and offboarding steps.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Self-serve AI building expands the NHI perimeter faster than most governance models assume. When non-engineers can create internal apps in a day, the number of service accounts, tokens, API keys, and deployment identities rises with the number of experiments. That is not just a productivity story. It means identity governance must extend into low-friction creator environments where access is granted for speed and forgotten after the demo. Practitioners should treat this as an expansion of the NHI estate, not a temporary innovation exercise.

Prebuilt scaffolding creates a governance gap if it is not paired with ownership boundaries. The article’s setup removed friction by wiring in GitHub Actions, cloud deployment, and secrets from the outset. That convenience is useful, but it also hides who owns which privilege after the first push. This is where lifecycle discipline matters: every scaffolded app should have a named owner, an expiry point, and a cleanup path. Practitioners should not confuse “easy to start” with “safe to leave running.”

Token sprawl is the real by-product of AI-assisted internal tooling. The hackathon depended on pre-provisioned access to internal systems so people could move quickly. That pattern normalises short-lived credential issuance for many small use cases, which is exactly how NHI sprawl begins. The security issue is not whether a team can build a Slack bot. It is whether the organisation can still account for every token, secret, and bot identity after the event ends. Practitioners should assume the prototype count will outlive the governance record unless ownership is explicit.

Named concept: hackathon identity debt. This article surfaces the hidden accumulation of identities, secrets, and permissions created when rapid internal building is optimised for speed first. The debt is not technical novelty. It is the lag between how quickly people can create access and how slowly those entitlements are reviewed, revoked, or rationalised. Practitioners should recognise this as a repeatable operating risk whenever self-serve AI development is encouraged.

Cross-actor governance now matters because AI accelerates human-led identity creation. The non-engineer is not autonomous, but the process still changes the load on human IAM, NHI issuance, and platform access controls at the same time. That combination makes the governance problem broader than app development alone. Practitioners should design review and offboarding processes for the human creator, the service account, and the deployment identity together.

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, which helps explain why self-serve building creates governance drift so quickly.
• For a broader view of how secret exposure turns into NHI risk, see LLMjacking: How Attackers Hijack AI Using Compromised NHIs.

What this signals

Hackathon identity debt: self-serve AI building creates a backlog of identities, secrets, and repository permissions that often outlives the prototype. With 6 distinct secrets manager instances on average across organisations, per The State of Secrets in AppSec, the governance challenge is fragmentation as much as volume.

Teams should expect AI-assisted internal development to blur the line between developer tooling and production authority. When build paths are prewired for speed, the access model needs explicit expiry, not implied cleanup.

The next maturity step is not better prompting. It is tighter lifecycle control over every temporary account, token, and deployment role created when non-engineers are allowed to build.

For practitioners

• Inventory hackathon-born identities Record every API key, token, service account, and deployment identity created for rapid internal building, then assign an owner and a removal date before the event ends.
• Separate build convenience from long-lived authority Keep scaffolded repositories, cloud roles, and GitHub Actions available only for the shortest time needed, then convert successful prototypes into governed production paths or shut them down.
• Apply lifecycle controls to prototype access Revoke unused secrets, rotate shared credentials, and confirm that no hackathon-issued access persists in Notion, Snowflake, Slack, or cloud environments after delivery.
• Map non-engineer-driven workflows to approval boundaries Define which actions a non-technical builder may trigger directly and which still require review, especially where code generation can reach deployment or data access.

Key takeaways

• AI-assisted internal building expands the non-human identity surface even when the builders are human.
• Preprovisioned access speeds delivery, but it also creates a cleanup problem that many teams do not operationalise.
• The control that matters most is lifecycle discipline for every token, secret, and deployment identity created for rapid prototyping.

Key terms

• Hackathon Identity Debt: The accumulation of temporary identities, secrets, permissions, and deployment paths created during rapid building events. It becomes debt when those entitlements are not cleaned up, reviewed, or re-owned after the prototype phase ends, leaving behind access that no longer matches any current business need.
• Self-Serve Build Access: An operating model where non-engineers can create or modify internal software with prewired access to repositories, cloud services, and secrets. It increases delivery speed, but it also shifts identity governance from a gated engineering process to a broader, more distributed access model that needs explicit lifecycle control.
• Prototype Secret Lifecycle: The full path of a temporary credential used to build and test a short-lived application, from issuance through use to revocation. In fast-moving internal programmes, this lifecycle is often where governance fails because secrets are created quickly but rarely reclaimed with equal discipline.

Deepen your knowledge

AI-assisted internal app building and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your teams are encouraging self-serve building, this is a practical place to align speed with control.

This post draws on content published by WorkOS: Claude Day: What happened when 39 teams let non-engineers drive. Read the original.