C1.ai onboarding shows how identity setup is becoming agentic

At a glance

What this is: This is C1.ai's analysis of goal-based, agentic onboarding for identity governance, showing how the product uses live tenant data to assemble setup steps, reviews, and AI access controls.

Why it matters: It matters because IAM teams now have to govern a setup process that behaves more like an execution agent than a static wizard, especially when people, apps, and AI agents are brought under one control plane.

By the numbers:

• A recent customer used C1.ai onboarding, out-of-the-box integrations, and AI connector builder to set up more than 150 apps in two days.

👉 Read C1.ai's blog post on agentic onboarding for identity governance

Context

Identity onboarding often fails because it asks teams to configure a platform before they have any value from it. The primary identity governance problem is not lack of controls, but the delay between setup effort and usable evidence, especially when directory data, app connectors, and access review routing all have to be stitched together manually. In this post, C1.ai reframes onboarding around the first outcome a team wants to reach, such as audit remediation.

That matters for IAM because the onboarding path is no longer just administrative setup. It is the first governance workflow, and if it is slow or opaque, the rest of the programme inherits that friction. For teams managing people, service accounts, and AI access together, the question becomes whether the onboarding flow preserves approval, traceability, and least privilege while reducing the time to a working result.

Key questions

Q: How should teams govern agentic onboarding in identity programmes?

A: Treat agentic onboarding as a governed execution path, not a setup convenience. Define which steps may be auto-assembled from live tenant data, which actions require review, and which sources of truth are authoritative for routing and evidence. The goal is a working control environment that is still explainable and auditable.

Q: What breaks when onboarding depends on manual configuration before any value appears?

A: Projects stall when every connector, mapping, and review rule has to be built by hand before the first outcome is visible. That delay weakens adoption, encourages bypasses, and makes governance feel optional. Faster paths matter because identity teams need evidence, routing, and control early enough to sustain momentum.

Q: How do AI access controls change when MCP tools are discovered at runtime?

A: MCP discovery turns tool access into an identity governance problem because each exposed tool becomes a potential action surface. Teams should assume new tools are sensitive until they are classified, approved, and tied to a clear user or agent purpose. Without that, runtime discovery can outrun policy.

Q: What should IAM teams do when autonomous workers can complete multi-step tasks?

A: They should review whether their current governance model assumes a human operator remains in the loop for the full task. If the worker can sequence work independently, then approval points, lineage, and post-action auditability need to be built into the flow rather than added afterwards.

Technical breakdown

Goal-based onboarding and live tenant discovery

Goal-based onboarding starts with the outcome the team wants, then uses the connected tenant to assemble the sequence of tasks needed to get there. In the article, that means the system detects the identity provider, pre-fills configuration, and reads directory relationships such as reporting lines and employment status. The design moves work from manual setup into guided task generation, which lowers configuration drag but also makes the discovery step foundational to governance accuracy.

Practical implication: verify that live discovery is accurate before you let onboarding drive access review or remediation workflows.

Governed agentic execution with approval gates

The article describes an autonomous worker that can plan and execute multi-step tasks across connected systems, but sensitive changes still route back for human approval. That distinction matters. The system is not simply automating clicks; it is selecting, sequencing, and executing work from an outcome-oriented request while preserving a decision gate for higher-risk actions. This is closer to governed execution than to a traditional workflow wizard.

Practical implication: classify which onboarding actions can be agent-assisted and which must remain approval-gated by policy.

AI access management and MCP tool governance

C1.ai places AI access on top of people governance, not beside it, and uses policy defaults for discovered MCP servers and exposed tools. MCP, the Model Context Protocol, connects AI agents to tools and data sources, so the identity question becomes who or what may invoke those tools and under what classification. The article shows approval required by default and sensitive classification for new tools, which is a governance pattern rather than a product feature.

Practical implication: treat every newly discovered MCP tool as a governed access surface until its use case, sensitivity, and approval path are explicitly set.

NHI Mgmt Group analysis

Goal-driven onboarding is now part of identity governance, not a prelude to it. When onboarding is built around live tenant discovery and a specific outcome, the governance model shifts from configuration to evidence-led action. That reduces setup friction, but it also means the onboarding flow becomes the first place where entitlement quality, manager coverage, and access routing are tested. Practitioners should treat onboarding as a control plane entry point, not a neutral setup wizard.

Agentic onboarding exposes a runtime governance assumption that many IAM programmes still make: setup happens before execution. That assumption was designed for static deployment flows where administrators configure systems in advance. It fails when an autonomous worker can plan, assemble, and carry out onboarding tasks from a goal because the setup path itself becomes operational work. The implication is that identity governance must account for decision-making inside the onboarding process, not just after deployment.

Managed AI access should inherit identity governance defaults from day one. The article's approach of placing AI access on the same foundation as people governance is directionally sound because it recognises that AI tools and MCP servers are additional identity surfaces, not separate exceptions. New tools defaulting to sensitive classification reflects the right bias for a still-immature control area. Practitioners should expect AI access governance to be treated as a first-class identity lifecycle problem.

Time to value is becoming a governance metric, not just an implementation metric. The customer example showing more than 150 apps set up in two days is less about speed as a sales claim and more about what modern identity programmes now compete on. If governance cannot reach a usable state quickly, teams will bypass it or delay it. The practical question is whether the first week of deployment produces evidence, routing, and approvals that teams can trust.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• That gap is why the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the next resource to use when onboarding becomes operational governance.

What this signals

Agentic onboarding creates a new lifecycle problem for IAM teams: the setup flow itself now issues, classifies, and routes access decisions before the programme has fully settled. That means the first control objective is no longer configuration completeness, but whether the system can produce trustworthy evidence on the first pass. Teams that cannot do that will find onboarding speed outpacing governance maturity.

The broader signal is that identity programmes will be judged on how quickly they can produce a controlled outcome, not just how many controls they can eventually assemble. Once AI access and MCP tools are folded into the same onboarding journey, the boundary between provisioning and runtime governance becomes thinner. Practitioners should prepare for review paths, approvals, and evidence collection to be designed as part of deployment from day one.

For practitioners

• Validate live tenant discovery before automation expands it Check that directory relationships, manager mappings, and employment status are correct before agentic onboarding uses them to drive review routing or remediation paths.
• Separate approval-gated actions from agent-assisted setup Define which onboarding steps an autonomous worker may plan or execute and which must wait for explicit human sign-off, especially where access changes are sensitive.
• Classify MCP tools as governed access surfaces Apply default sensitive classification to newly discovered MCP tools until the use case, data exposure, and approval requirements are documented and reviewed.
• Measure time to first governed outcome Track how long it takes a new deployment to produce a signed-off access review, not just how long it takes to complete configuration.

Key takeaways

• Identity onboarding is moving from manual setup to governed execution, which changes where practitioners need to apply control.
• Live discovery, approval gates, and default-sensitive classification are the mechanisms that keep agentic onboarding auditable.
• Teams should measure time to first governed outcome, not just time to deployment, because speed without evidence does not sustain identity governance.

Key terms

• Agentic onboarding: An onboarding process in which software assembles and executes setup tasks from a goal rather than requiring an administrator to drive each step manually. In identity governance, this matters because the setup path itself becomes part of the control environment and must remain auditable.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Lineage Tracking: Lineage tracking records how a model or dataset was created, changed, and reused over time. It gives security, compliance, and engineering teams a defensible history of dependencies, which is essential when proving what was tested, approved, and deployed.
• Sensitive classification: Sensitive classification is the practice of treating a newly discovered identity surface as high risk until its purpose, access scope, and approval path are defined. For AI tools and NHIs, it is a safe default because exposure often exists before governance does.

What's in the full article

C1.ai's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact onboarding sequence used to turn a goal into setup tasks inside the tenant.
• How the agent drafts access review work and where human approval is still required.
• The mechanics of AI access management for discovered MCP servers and tools.
• The example of how the autonomous worker produces lineage trails for auditability.

👉 C1.ai's full post covers the onboarding flow, AI access controls, and autonomous worker lineage in more operational detail.

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.