Who should own governance when AI agent sessions become expensive and persistent?

Why This Matters for Security Teams

When AI agent sessions become persistent and costly, the governance question stops being only about access and starts becoming about operational ownership, spend control, and risk acceptance. A session that keeps credentials, tool access, and context alive for hours or days can create hidden blast radius, especially when the business team sees productivity gains while platform and IAM teams absorb the failure modes. This is why guidance is converging on shared accountability rather than single-owner governance, as reflected in the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10.

NHIMG research on OWASP NHI Top 10 and the State of Secrets in AppSec shows how quickly control fragmentation appears once credentials, runtime policy, and business usage are managed in separate lanes. In practice, many security teams encounter runaway agent cost and overbroad persistence only after a tool-heavy workflow has already been promoted into production without an explicit owner for its ongoing session budget.

How It Works in Practice

The practical answer is to assign governance across three layers with one accountable decision path. Platform engineering owns the runtime, session infrastructure, logging, and guardrails that determine how long an agent can stay alive. IAM owns workload identity, secret issuance, and revocation mechanics so the agent is not depending on static credentials. The business owner owns the use case, value threshold, and approval to keep the agent active when costs rise or the workflow expands.

That split matters because persistent agent sessions behave more like long-lived workloads than user logins. Best practice is evolving toward just-in-time credentials, short TTLs, and runtime authorization that is evaluated at the moment the agent requests a tool or data source. Current guidance also favors workload identity over shared secrets, using approaches such as SPIFFE or OIDC-backed token exchange to prove what the agent is, not just what secret it holds. Policy evaluation should happen at request time, informed by context such as task scope, data sensitivity, and session age.

Security teams should document three operational controls:

• Session ownership: who can extend, pause, or terminate the agent session.
• Cost ownership: who approves long-running compute, tool calls, and external API spend.
• Risk ownership: who accepts the blast radius if the agent chains tools or repeats actions.

That governance model aligns well with NHIMG guidance in Ultimate Guide to NHIs 2025 Outlook and Predictions and incident patterns seen in CoPhish OAuth Token Theft via Copilot Studio. These controls tend to break down in shared-service environments where one platform team runs the agent, another team funds the cloud account, and no business owner is forced to justify continued execution.

Common Variations and Edge Cases

Tighter governance often increases friction for product teams, so organisations must balance shorter sessions and stronger approvals against delivery speed and user experience. That tradeoff becomes sharper when an agent supports customer-facing workflows, internal copilots, or always-on operations where repeated reauthentication would interrupt legitimate work.

There is no universal standard for how long an AI agent session should remain active. Current guidance suggests using the shortest practical TTL, but some workflows need longer-lived context to complete multi-step tasks. In those cases, the safer pattern is to refresh authorization in small increments rather than granting one broad persistent session. This is especially important when the agent can call external tools, write to systems of record, or move laterally across data sources.

Edge cases also appear when finance, legal, or operations teams buy the agent directly. In those environments, platform engineering may still control runtime and IAM may still control credentials, but the business unit must own the ongoing justification because it controls the value case. NHIMG incident coverage such as Replit AI Tool Database Deletion and Amazon Q AI Coding Agent Compromised shows why ownership must include both operational control and business accountability, especially when agent sessions can outlive the original approval.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• Who should own the decision to self-host agent governance infrastructure?
• Who should own AI agent data controls when NHI and IAM overlap?
• What makes agentic AI an NHI governance issue?