Notifications
Clear all
Topic starter
06/06/2026 1:36 am
TL;DR: AI-assisted building changes who can create operational software, but not who must own access, secrets, and deployment guardrails, according to WorkOS. Its one-day Claude Day hackathon paired 39 teams around a non-technical driver and prebuilt scaffolding, so participants shipped internal AI tools without spending the morning on setup friction.
NHIMG editorial — based on content published by WorkOS: Claude Day: What happened when 39 teams let non-engineers drive
By the numbers:
- 39 teams built AI-powered internal tools during Claude Day.
Questions worth separating out
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.
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.
Q: What breaks when AI-generated internal tools are left running after a hackathon?
A: The access model breaks first.
Practitioner guidance
- 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.
What's in the full article
WorkOS's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact hackathon scaffolding used to get non-engineers from idea to deployed app fast.
- Examples of the internal tools teams built across product, marketing, sales, and operations.
- The practical setup choices behind the wow CLI, GitHub Actions wiring, and pre-provisioned secrets.
- The lessons non-engineers shared about prompting, debugging, and shipping with Claude.
👉 Read WorkOS's Claude Day write-up on non-engineer-led AI building →
Non-engineer-led AI hackathons: what they change for IAM teams?
Explore further
06/06/2026 2:49 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Non-engineer-led AI hackathons change internal tool delivery
