Platform control decides where the AI lifecycle runs and how infrastructure is operated. Runtime control decides what an agent may do after it starts, including which tools, data and destinations it can reach. Both are necessary, but they answer different governance questions and fail in different ways.
Where platform control and runtime control split
Platform control governs the environment the agent runs in: where it is hosted, what infrastructure it can reach, how deployments are configured, and which operator-level guardrails exist before any agent action occurs. Runtime control governs the agent’s live behaviour after launch: the tools it may call, the data it may read, the destinations it may contact, and the conditions under which each action is approved or blocked.
The practical difference is that platform control shapes the operating envelope, while runtime control shapes each decision inside that envelope. A strong platform control posture can still leave an agent overly powerful at runtime, and strong runtime policy cannot compensate for a weak platform that exposes secrets, broad network reach, or unsafe deployment defaults.
How governance questions change once the agent is live
Platform control answers questions about ownership, isolation, tenancy, patching, environment separation, and whether the agent platform itself is trusted to operate safely. Runtime control answers questions about delegated authority, tool scope, per-action approval, destination restrictions, and whether a specific request is acceptable in the current context.
That split matters because the control objective changes. Before execution, the concern is whether the platform can be operated without creating a large blast radius. During execution, the concern is whether the agent can be constrained tightly enough that a mistaken prompt, poisoned context, or malicious instruction does not translate into unrestricted action.
For governance teams, the cleanest mental model is to treat platform control as infrastructure and lifecycle governance, and runtime control as authorization and enforcement. That distinction helps avoid the common error of assuming that hardening the environment automatically limits what the agent can do once it is active.
Why both controls fail in different ways
Platform control tends to fail through misconfiguration, weak isolation, overbroad access to the underlying cloud or orchestration layer, and poor separation between development, test, and production environments. If the platform is exposed, the agent may inherit dangerous reach even before its own policies are evaluated.
Runtime control tends to fail when policies are too coarse, tool permissions are static, approvals are skipped for convenience, or enforcement is disconnected from the actual action the agent is taking. In those cases, the agent may operate inside a supposedly governed platform while still being able to exfiltrate data, invoke sensitive tools, or act beyond the original task scope.
AI Agent Authorisation Guide is useful here because it frames runtime governance around least privilege, task-scoped access, and per-action decisions. Zero Trust for AI Agents adds the complementary point that runtime trust should be continuously verified, not assumed after startup.
Risk and Threat Considerations
When platform control and runtime control are blended together, teams often miss the real failure path: the platform may be hardened enough to look safe, yet the agent still has enough live authority to cause material damage. That is especially dangerous when an agent can combine broad runtime permissions with access to sensitive tools, data stores, or external destinations.
Failure mechanism: An attacker or faulty prompt can exploit excessive platform reach, weak environment isolation, or overpermissive runtime policy to move from a single agent action to wider data exposure, unauthorized transactions, or lateral access into adjacent systems.
Impact: The result can be scope creep in privileges, loss of containment, difficult-to-audit actions, and a larger blast radius than the business expected from an individual agent workflow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Covers agent authority misuse, which depends on runtime control scope. |
| Recommendation — Enforce per-action authorization to prevent agents from exceeding assigned privilege. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Directly supports limiting an agent's runtime permissions to only what it needs. |
| CM-2 — Baseline Configuration | Applies to platform control because deployment and environment baselines shape safe agent hosting. | |
| SC-7 — Boundary Protection | Supports platform isolation and controlled outbound reach for hosted agents. | |
| Recommendation — Restrict agent access to the minimum permissions required for the task. Define and maintain secure platform baselines for agent hosting and orchestration. Segment agent platforms and constrain external connections at the boundary. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Zero Trust Architecture Principles | Matches the need to verify agent requests continuously rather than trusting startup state. |
| Recommendation — Continuously verify each agent request before allowing access or action. | ||
Practitioner Guidance
What to verify: Confirm that platform permissions and runtime permissions are reviewed separately. A platform assessment should ask whether the hosting and deployment layer is isolated correctly; a runtime assessment should ask whether each tool, dataset, and outbound destination is explicitly justified for the task.
Decision rule: If the agent can reach something that would be unacceptable for the operator to do manually without approval, treat that as a runtime control gap even if the platform itself is well secured. If the platform can expose secrets, tokens, or broad network access by default, treat that as a platform control gap even when runtime policy exists.
What good looks like: The platform is constrained enough that compromise of one agent instance does not expose the wider environment, and the runtime layer is narrow enough that each sensitive action is evaluated against the current task, not a standing role.
Practitioner takeaway: Platform control reduces the agent’s operating surface, but runtime control limits the agent’s actual authority, and you need both because each one fails independently.
Related resources from NHI Mgmt Group
- What is the difference between static policy and runtime control for AI agents?
- What is the difference between access scope and runtime control for AI agents?
- What is the difference between prompt-based control and runtime authorization for agents?
- What is the difference between access control and attribution for AI agents?