AI agent governance and runtime control are the real conference agenda

At a glance

What this is: C1.ai’s Transform 2026 conference puts AI agent governance, runtime control, and security-operations use cases at the centre of the agenda.

Why it matters: It matters because practitioners now have to govern agent privilege, execution context, and operating boundaries, not just model access or prompt quality.

👉 Read C1.ai's agenda for AI agent governance and runtime control at Transform 2026

Context

AI agent governance is the control problem that appears once an agent can take actions, not just generate text. In that setting, the risk shifts from model behaviour alone to who can authorise the agent, where it runs, what it can touch, and how its actions are bounded.

This conference agenda points to a genuine governance gap in many programmes: teams are still treating agents like advanced chat interfaces, while the operational issue is closer to machine identity, delegated privilege, and runtime containment. For identity and security teams, the question is whether existing approval and sandbox patterns can keep pace with agentic execution.

The event date makes the discussion timely, but the underlying issue is durable: if an agent can act faster than a human can review, governance has to move earlier in the control path.

Key questions

Q: How should security teams govern AI systems that can act without human approval?

A: Security teams should govern autonomous AI the same way they govern other high-risk identities, but with runtime enforcement instead of periodic review. That means tightly scoping tools, data, and actions; logging every material step; and making revocation and containment available while the session is still active. Static policy alone does not control machine-paced execution.

Q: Why do AI agents create risk even when they stay within approved permissions?

A: AI agents can be authorised correctly and still produce harmful outcomes because permission is not the same as intent or behavioural appropriateness. If an attacker manipulates the session mid-flight, the agent may keep acting inside scope while exfiltrating data, taking destructive steps, or chaining actions that no human would have approved.

Q: What are the signs that an AI agent access model is becoming too permissive?

A: Warning signs include agents routinely reaching data outside their intended task, repeated approval exceptions, broad retrieval paths across unrelated systems, and outputs that expose information the user did not explicitly need. If the same agent is allowed to touch many data domains without clear policy boundaries, the control model is drifting away from least privilege.

Q: How should organisations decide which security operations are suitable for agentic automation?

A: Use reversibility and decision risk as the main filters. Good candidates are tasks with constrained inputs, observable outputs, and low-cost rollback. Poor candidates are actions that require broad judgment, have irreversible impact, or depend on context that a model cannot reliably validate on its own.

Background and context

Why agent governance starts after the credential perimeter

AI agents do not become risky only when they are connected to sensitive data. They become governable problems when they can obtain credentials, invoke tools, and make runtime decisions without a person approving each action. That changes the security model from prompt filtering to delegated authority control. In practice, identity, authorisation, and execution context become inseparable because the agent is operating as a software actor with a changing risk profile. The core question is not whether the model is useful, but whether its privileges are bounded tightly enough to prevent unauthorised action at machine speed.

Practical implication: treat agent identity and delegated authority as first-class controls, not as an add-on to model access.

Why Kubernetes is not automatically the right runtime for agent sandboxes

Kubernetes gives teams orchestration, isolation primitives, and policy hooks, but it does not by itself solve agent containment. An agent sandbox needs controls for identity, tool access, network reach, state handling, and lifecycle termination. If those controls are not designed around the agent’s actual behaviour, the cluster becomes a convenient wrapper rather than a security boundary. The runtime question is therefore about trust boundaries, not just infrastructure preference. For agentic systems, the relevant security issue is whether the runtime can enforce least-privilege execution and clean separation between tasks, contexts, and identities.

Practical implication: validate sandbox design against agent privilege, state, and tool-use boundaries before standardising on a runtime.

Why security teams must decide where agents actually create value

Agentic AI is not automatically useful in every security workflow. Some tasks benefit from speed and pattern execution, while others still require human judgment, escalation context, or accountability that cannot be delegated safely. The governance mistake is to assume that any repetitive security task is a candidate for autonomy. In reality, the best-fit use cases are the ones where the decision path is constrained, measurable, and reversible. This is where AI security governance intersects with operating model design: the issue is not just what agents can do, but what they should be allowed to do without eroding control integrity.

Practical implication: map use cases by decision risk and reversibility before assigning agentic workflows to security operations.

NHI Mgmt Group analysis

Agent governance is now an identity problem, not only an AI problem: once software can decide when to act, the security question becomes who or what authorised that action and under which constraints. Traditional approval workflows assume a human remains in the loop long enough to inspect the act before execution. In agentic systems, that assumption breaks, so identity, privilege, and runtime policy have to be managed together. Practitioners should treat agent authority as a governed identity plane.

Runtime control is the missing control layer for agentic AI: many teams are focusing on model policy while leaving execution boundaries under-specified. That creates a trust gap between the decision made by the model and the action taken by the runtime. Sandboxing, network egress control, and per-task privilege scoping matter because they define what the agent can do after the model speaks. Practitioners should evaluate whether the runtime can actually enforce the policy the governance team thinks it has.

AI agent governance debt is accumulating faster than most programmes can measure: every new workflow that grants an agent tool access adds lifecycle, accountability, and offboarding burden. The danger is not just overuse, but unmanaged re-use of the same credentials, contexts, or approvals across tasks. In identity terms, that is a control lifetime problem. Practitioners should inventory agent authority the same way they inventory privileged service accounts.

The market is converging on evidence that autonomy without execution guardrails is incomplete: conference agendas are increasingly centring on governance after the credential perimeter rather than model performance alone. That signals a broader shift in the field toward runtime attestation, delegated authority reviews, and workload-style identity thinking for agents. Practitioners should expect vendor and framework discussions to move from prompt safety to operational control.

Where agents deliver value will be defined by reversibility, not novelty: the strongest use cases are the ones where the action can be bounded, observed, and rolled back. That is a governance principle as much as a technical one. Teams that cannot demonstrate those properties should delay autonomy and keep humans on the critical path until controls mature.

What this signals

Agentic AI governance debt is becoming a programme-level issue: every agent that can act creates a new identity, privilege, and revocation obligation. Security teams should expect inventory discipline to matter as much as model governance, because unmanaged agent sprawl quickly turns into unmanaged authority.

The practical shift for practitioners is from approving outputs to governing execution boundaries. That means aligning agent use cases to reversible actions, constrained tool access, and explicit offboarding, while treating runtime policy as part of the control plane rather than a technical detail.

For practitioners

• Define agent authority boundaries Document exactly which actions an agent may take, which tools it may call, and which approvals are required before execution.
• Separate sandbox runtime from production trust Test whether the chosen runtime can enforce isolation for credentials, network access, task state, and termination across agent sessions.
• Inventory agent credentials and approvals Track every token, service account, or delegated identity used by an agent so offboarding and revocation are possible at task completion.
• Limit agent use to reversible workflows Reserve agentic execution for tasks where actions are bounded, observable, and can be rolled back without business disruption.

Key takeaways

• AI agent governance now sits at the intersection of identity, authorisation, and runtime control, not just model policy.
• The most consequential gap is the distance between what an agent is allowed to decide and what it is allowed to execute.
• Security teams should narrow agentic use to reversible workflows and enforce task-scoped privilege from issuance to revocation.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Runtime control: Controls that enforce policy while an AI system is operating, rather than after the fact. For healthcare chatbots, runtime control includes data masking, output filtering, access scoping, and immutable logging so the organisation can defend the interaction itself.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
• Task-Scoped Least Privilege: A permission model that limits an agent or service identity to only the systems and data required for a specific task. It reduces exposure by preventing a non-human system from carrying unnecessary access into every workflow it executes.

What to expect at the briefing

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

• Session-by-session agenda detail for AI agent governance, runtime control, and security operations
• Speaker lineup and role context for practitioners comparing governance, architecture, and security viewpoints
• Event logistics, venue information, and timing for attendees planning to join the conference
• The specific sequence of talks covering agent sandboxes, runtime boundaries, and operational use cases

👉 The full C1.ai event page lists the sessions on agent governance, runtime sandboxes, and security operations use cases.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, agentic AI identity, machine identity security, and secrets management in a practical, practitioner-led format. It is the industry's only accredited NHI security programme, designed for teams building the controls that keep identity governed across human and non-human systems.