How should organisations govern AI systems that can change scope at runtime?

They should treat runtime behaviour as part of the compliance boundary. That means inventorying every model, tool, and integration, then checking whether the system still acts within its intended purpose after deployment. Static approval is not enough when an agent can expand scope through chained actions or delegated workflows.

Why This Matters for Security Teams

When an AI system can change scope at runtime, the real security question is not whether it was approved at launch, but whether its current actions still match its intended purpose. That is a direct governance problem because autonomy lets the system combine tools, follow prompts, and extend influence in ways that static review never anticipated. Guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward continuous control validation, not one-time trust.

This is especially important for agents that can invoke APIs, pass tokens to downstream tools, or inherit permissions through delegated workflows. NHIMG research on Top 10 NHI Issues highlights how quickly trust breaks down when machine identities are not bounded by lifecycle, scope, and revocation discipline. In practice, many security teams encounter misuse only after an agent has already chained actions across systems, rather than through intentional scope testing.

How It Works in Practice

Governance should start by treating runtime scope as part of the compliance boundary. That means mapping the system’s model, tools, connectors, prompts, and delegated permissions as one operating unit, then checking whether each task remains within the approved purpose. For agentic systems, static RBAC is usually too blunt because the workload is not behaving like a human user with stable access patterns. Current guidance suggests combining workload identity, policy evaluation, and time-bound authorization so decisions happen at request time, with full context.

A practical control set looks like this:

• Use workload identity for the agent so the system can prove what it is, not only what secret it holds.
• Issue just-in-time credentials with short TTLs, then revoke them automatically after task completion.
• Evaluate policy at runtime through policy-as-code rather than relying only on pre-approved entitlements.
• Log every tool call, token exchange, and delegated action so scope drift can be detected and reviewed.

This approach aligns with the operational direction of the Ultimate Guide to NHIs for lifecycle management, especially where identity issuance, rotation, and retirement need to track actual system behaviour. It also fits the broader NIST framing around continuous risk management, where a system’s trust level changes as conditions change. For implementation detail, teams often look to SPIFFE-style workload identity and OIDC-based short-lived tokens, but best practice is still evolving for multi-agent architectures. These controls tend to break down when agents are allowed to chain opaque third-party tools because policy cannot reliably inspect or constrain the downstream action path.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance safety against developer velocity and system availability. That tradeoff becomes sharper when agents support customer-facing automation, where strict approval gates can slow response times or reduce usefulness. There is no universal standard for this yet, so governance should be risk-based rather than uniformly restrictive.

One common edge case is delegated scope, where an agent inherits access from another workflow or service account. Another is prompt injection or tool manipulation, where the system remains technically within its permissions but is functionally pushed beyond its intended purpose. NHIMG’s regulatory and audit perspective reinforces that auditors will care less about design intent than about demonstrable control evidence: task logs, approval traces, revocation records, and exception handling. If secrets are involved, the 44% developer best-practice gap reported in The State of Secrets in AppSec is a reminder that long-lived credentials magnify runtime scope drift. The hardest cases are systems that can self-select tools across environments, because boundary checks often fail once the agent can move laterally through multiple trusted services.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• When should organisations move from policy design to runtime enforcement for AI systems?
• How should organisations govern AI systems that can make consequential decisions?
• How should security teams govern AI agents that can change behaviour at runtime?