TL;DR: C1.ai says internal apps are being built fast enough that sign-in, permissions, credentials, and offboarding now need to start at creation time, not after distribution, because local workarounds and shared API keys leave new apps unmanaged. Governed app delivery becomes an identity problem as much as a software problem.
At a glance
What this is: C1.ai describes a self-hosted app governance platform that ties deployment, authentication, permissions, and credentials to the moment an internal app is created.
Why it matters: IAM, IGA, PAM, and NHI teams need to treat internal app creation as a governance event, because visibility and offboarding collapse once teams can build and share apps without central control.
👉 Read C1.ai's article on self-hosted governance for AI-built internal apps
Context
The core governance gap is not app development speed. It is the assumption that visibility, ownership, and access controls can be added after a team has already created and shared an internal application. In AI-assisted environments, that assumption breaks quickly because the build path is now also the distribution path.
Self-hosted app governance matters because internal apps inherit identity risk the moment they are shared. If sign-in, permissions, credentials, and model calls are not governed at creation time, teams fall back to hand-written user lists, shared API keys, and ad hoc offboarding that the enterprise cannot reliably audit.
Key questions
Q: How should teams govern internal apps that can be built and shared quickly?
A: Teams should make governance part of the build path, not an afterthought. That means every internal app should carry a recorded owner, approved sign-in method, explicit permissions, and a revocable credential source before it is shared. The goal is to prevent each new app from becoming an unmanaged access island.
Q: Why do shared API keys create so much risk in internally built apps?
A: Shared API keys collapse accountability because multiple users and apps can rely on the same credential with no clean ownership boundary. They also make offboarding and review nearly impossible, since the credential can outlive the people or projects that first used it. That is how a convenience shortcut becomes persistent identity sprawl.
Q: How do security teams know whether an internal app is properly governed?
A: Look for whether the app has a verified identity, a named owner, shared authorization decisions, scoped credentials, and a defined offboarding path. If those elements live only in local code or informal team knowledge, the app is operating outside the programme even if it works correctly.
Q: What is the difference between governed app delivery and ordinary deployment automation?
A: Governed app delivery ties identity decisions to the application itself, including who owns it, how users sign in, and where credentials come from. Ordinary deployment automation can publish code without creating that accountability trail. The difference is whether the app enters production with an auditable access model or with hidden exceptions.
How it works in practice
Why app creation now needs governance baked in
AI coding tools compress the time between idea and deployed application, which changes the control point for identity governance. When builders can create an internal app in a morning, the risky moment is no longer production handoff, it is the first prompt that creates the app and its access model. That means ownership, sign-in, and permission decisions must be available during the build workflow, not added later as a separate governance step. The architecture problem is not deployment alone. It is whether the application is born with a traceable identity and an auditable access boundary.
Practical implication: Design governance so app identity, ownership, and permissions are established before the first deployable build is created.
Why shared API keys and user lists create identity sprawl
The article points to a familiar failure mode: builders use local workarounds when the governed path is harder than the unmanaged one. Shared API keys, handwritten user lists, and locally held credentials bypass the normal lifecycle controls that IAM and NHI programmes rely on. Once those shortcuts spread across many small apps, the enterprise gets fragmented access state instead of one governable identity layer. In practice, that turns each app into a separate mini-directory with its own offboarding burden and no consistent review evidence.
Practical implication: Eliminate ad hoc access patterns by making governed sign-in and credential sourcing easier than shared secrets or manual access lists.
How AI coding agents change the deployment boundary
The repository-plus-prompt model shifts application delivery into an agent-assisted workflow. In this pattern, an AI coding agent does not just assist with code generation, it can help build and publish a governed application in one path. That matters because the identity controls for the resulting app need to be part of the same workflow that creates it. If the build system can also publish the app, then governance has to cover the full chain from code generation to deployment, not just the runtime environment after the fact.
Practical implication: Treat AI-assisted app build and publish workflows as governed identity workflows, not just software delivery automation.
NHI Mgmt Group analysis
Governed app creation is becoming an identity control point, not a software convenience. C1.ai's framing is really about where authority sits when internal apps are built quickly and shared just as quickly. The important shift is that sign-in, permissions, credentials, and offboarding can no longer be layered on after distribution if the organisation wants reliable accountability. For practitioners, app creation itself now belongs inside the identity governance model.
Shared API keys are the clearest sign that governance has lost the build path. When teams resort to handwritten user lists and shared credentials, the enterprise has already accepted an unmanaged identity surface. That surface is especially dangerous for internal apps because each one becomes a small but durable access domain with its own exceptions. The practitioner takeaway is that unmanaged convenience becomes identity sprawl almost immediately.
Build-time identity binding: the governance pattern that matters here is tying application identity, owner identity, and credential sourcing together before the app ships. That concept is useful because it captures the real control requirement without reducing it to deployment hygiene. Once the app exists in a shared environment, ownership and access drift become harder to prove and harder to reverse. Teams should treat build-time binding as the baseline for governable internal apps.
The self-hosted model matters because it keeps the workload, network, and data in the organisation's own boundary. That does not remove governance needs, but it does reduce the excuses for fragmented control planes. When internal apps are born inside the enterprise's own environment, reviewers should expect consistent identity records from day one. The implication for IAM and NHI teams is that app governance can be designed as a standard pattern rather than a case-by-case exception.
AI-assisted app delivery widens the gap between what can be built and what can be governed. The article describes a world where one prompt can create and publish an app, which means the review burden moves earlier in the lifecycle. If the governance layer does not keep pace, access review and offboarding become retrospective exercises over assets that were never brought into the control model properly. Practitioners need a build-path governance stance, not a post-deploy cleanup mindset.
What this signals
Build-time identity binding: internal apps need an identity record at the moment they are created, not after they begin circulating inside the company. If ownership and access are established later, reviewers are left reconstructing control from incomplete evidence rather than governing the app as it is born.
The practical shift for programme owners is to treat AI-assisted app creation as a governed lifecycle event. That means access reviews, offboarding, and credential sourcing must attach to the app from the first deployable version, or the organisation will keep creating unreviewable exceptions.
For practitioners
- Define app identity at creation time Require every internal app to have an owner, sign-in configuration, and permissions model before it is shared beyond the builder.
- Replace shared secrets with governed credential sourcing Move applications away from handwritten user lists and shared API keys so credentials come from a controlled identity service instead of local storage.
- Bring AI-assisted builds into the governance workflow Treat repository-to-deploy automation as part of identity governance so the build process cannot bypass policy decisions about access, credentials, and publishing.
- Extend access reviews to internally built apps Make newly created internal apps visible in the identity graph immediately so review and offboarding processes apply on the first day.
Key takeaways
- Internal app governance is moving into the build path because AI-assisted development can create and distribute new apps faster than traditional control processes can catch up.
- Shared API keys and handwritten access lists are not minor shortcuts. They are the point where identity governance fractures into app-specific exceptions.
- The strongest control change is to bind ownership, sign-in, permissions, and credential sourcing before an app is shared, so review and offboarding start on day one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared app credentials and broad access patterns create overprivileged internal apps. |
| NHI-10 — Human Use of NHI | Builders are using human workflow shortcuts to manage app access and credentials. | |
| Recommendation — Apply NHI-05 to remove broad app permissions and force least-privilege access at build time. Reduce manual handling of app credentials and route access through governed identity services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on authorisation for internal apps and their lifecycle visibility. |
| Recommendation — Align internal app governance with PR.AA-05 so permissions are explicit and reviewable. | ||
| MITRE ATT&CK | TA0003;TA0006 — Persistence; Credential Access | Persistent shared access and credential shortcuts are the core abuse pattern discussed. |
| Recommendation — Map unmanaged internal app access to persistence and credential-access behaviors in detection and review. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article describes AI-assisted app creation and privilege assignment through an agentic workflow. |
| Recommendation — Govern agent-assisted build workflows so privilege assignment cannot occur outside policy. | ||
Key terms
- Build-time identity: Build-time identity is the set of service accounts, tokens, and permissions used by CI/CD systems, testing tools, and deployment automation. It matters because these identities often carry production access and can turn development speed into an access-control problem if they are over-privileged or poorly governed.
- Identity Graph: An identity graph is a relationship map that connects identities, assets, data, and permissions so teams can see how access actually flows. In NHI programmes, it helps explain which agent is related to which owner, which system, and which policy boundary.
- API Key Sprawl: API key sprawl is the uncontrolled growth of API keys across systems, teams, and environments. It occurs when keys are created, copied, stored, rotated, or retired without consistent governance. This increases exposure to theft, misuse, privilege accumulation, and audit gaps, especially when keys are embedded in code, scripts, pipelines, or shared documentation.
What's in the full announcement
C1.ai's full article covers the operational detail this post intentionally leaves for the source:
- How C1 AppHub structures the repository, skills file, and MCP server workflow that builds and publishes an app
- How sign-in, permissions, credential sourcing, and model-call routing are tied into the governed app pattern
- How the platform represents each app in the identity graph for review and offboarding
- How C1.ai describes the self-hosted deployment model for teams running these apps in their own cloud
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 programme, it is worth exploring.
Published by the NHIMG editorial team on September 30, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org