Install-time review is the human approval of a package or configuration, while runtime trust is the actual behaviour once the tool starts using persisted settings. In agent tooling, those can diverge, so governance has to verify the effective configuration after persistence, not only the preview shown at install.
Why install-time review and runtime trust are different control moments
Install-time review is a gate on what the user approves before a tool is added; runtime trust is the security state after the tool is already installed, configured, and acting with whatever permissions and persisted settings it actually has. The difference matters because an approved package can behave differently once it starts reading stored credentials, inherited scopes, or persisted policy.
That is why AI Agent Authorisation Guide is useful here, the real question is whether the agent is authorised for the action it will execute, not just whether the tool was approved for installation.
A second useful distinction is that install-time review is usually static and bounded, while runtime trust is dynamic and conditional. A tool can pass review on paper and still become unsafe if the active configuration changes through persistence, inheritance, remote policy updates, or a later action that expands scope beyond the preview shown to the reviewer.
Where divergence usually shows up in agent tools
In agent tooling, divergence often appears when the install prompt describes one capability but the running system inherits another. Common examples include hidden default scopes, saved tokens, connector permissions, policy changes after approval, and “remembered” settings that change how the tool behaves across sessions.
The practical implication is that the security boundary is not the approval dialog, it is the effective permissions set after persistence. For that reason, MCP Security Guide matters because it focuses on authorisation, token handling, and tool configuration rather than assuming the install prompt tells the whole truth.
This also explains why runtime evidence is often more trustworthy than install-time intent. If the agent can reach a connector, call a tool, or use a persisted secret in production, then governance should treat that as the operative security state, even if the original install review looked narrow.
How to govern the effective configuration, not the preview
Good governance checks what the tool can actually do after persistence, not only what it said it would do at install. That means reviewing the stored configuration, the active permission model, the token or secret lifetime, and the concrete actions the agent can trigger once it starts operating.
For agent stacks that chain tools or delegate across services, install-time approval is especially weak as a sole control. Zero Trust for AI Agents is the better operational frame because it requires verification at the point of use, not just at onboarding.
Where possible, teams should separate approval of the package from approval of the privileges. That lets you keep useful automation while still requiring the runtime environment to prove it is operating within the intended boundaries, especially after updates, reconfiguration, or credential refresh.
Risk and Threat Considerations
Install-time review creates a false sense of safety when the runtime state can expand through persistence, inherited credentials, or later configuration drift. The exposure is highest when an agent can retain access across sessions, because the approved surface can silently grow after the initial review.
Failure mechanism: the reviewer approves a benign-looking package or config, but the running tool later activates broader permissions, reuses stored secrets, or follows a changed policy path that was not visible at install.
Impact: the agent may perform actions outside the intended trust boundary, which can lead to unintended data access, over-privileged tool use, or delegated actions that are hard to trace back to the original approval.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent tool trust hinges on whether runtime privilege exceeds the install-time review. |
| ASI02 — Tool Misuse | Installed tools can later be used in ways not apparent at review time. | |
| ASI08 — Cascading Failures | Persisted config drift can cascade into broader agent compromise or misuse. | |
| Recommendation — Enforce per-action authorisation and block privilege expansion after install. Validate tool behaviour at runtime and restrict unsafe tool actions. Contain runtime changes so one approval cannot expand into system-wide impact. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Runtime trust must limit the effective permissions actually available to the tool. |
| IA-5 — Authenticator Management | Persisted secrets and tokens often determine the real runtime trust boundary. | |
| Recommendation — Constrain the tool to the minimum runtime permissions required. Rotate and protect persisted credentials that govern tool runtime access. | ||
Practitioner Guidance
What to verify: Treat install approval as incomplete until you verify the effective runtime configuration, including persisted settings, active scopes, connector grants, and any credentials the tool can reuse after launch.
Decision rule: If the tool can do more after persistence than it could at review time, govern the runtime state as the source of truth and require the higher-risk path to be explicitly approved or constrained.
What good looks like: install-time intent, stored configuration, and observed runtime behaviour all match, and any change in privilege or tool access is visible, auditable, and reviewable before it takes effect.
Practitioner takeaway: The safe control point is not the approval screen alone, it is the combination of approval plus verified runtime behaviour after persistence.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between governing human access and governing AI agent access?
- What is the difference between static API-key access and execution-time authorized OAuth access for agent tools?
- What is the difference between build-time supply chain review and runtime script governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org