Because the risky part can already exist in MCP servers, plugins, skills, hooks, and configuration drift before the first prompt. Those components influence what the agent can see and do, so the control boundary has to begin at inventory and policy evaluation. If setup is trusted blindly, the session begins with hidden exposure already in place.
Why the governance boundary starts before the first Claude prompt
Claude agents are not only shaped by the prompt. Their real operating boundary is also set by the MCP servers, plugins, skills, hooks, and configuration state already attached to the session. If those inputs are unreviewed, the agent can begin with inherited reach, hidden tools, or unexpected data access before any runtime action is visible.
The practical implication is that governance has to treat pre-runtime setup as part of the control surface. Inventory, policy evaluation, and trust decisions must happen before the agent is allowed to act, because the initial environment can already define what the agent can see, call, or leak.
What makes pre-runtime setup a governance problem rather than a mere deployment detail?
Pre-runtime setup becomes a governance issue when it changes authority, exposure, or decision boundaries without a live interaction ever occurring. A plugged-in server, an added skill, or a stale configuration can expand access, redirect tool use, or silently connect the agent to resources the operator did not intend to expose. That is a control problem, not just an engineering convenience.
In practice, the question is less “what will the model say?” and more “what can this session already reach?” If the answer depends on undocumented MCP endpoints, inherited tokens, or environment-specific hooks, then the governance decision has already been made upstream. The runtime prompt only inherits that decision.
A useful way to think about this is the relationship between inventory and authority. Inventory tells you what is present. Policy evaluation tells you whether each component should be trusted, connected, and allowed to influence the agent. Without both, the agent may start life inside an unexamined trust boundary.
What should practitioners inspect before allowing the agent to run?
Start with the components that can alter capability before the first prompt. That means enumerating connected MCP servers, checking what each one can expose, reviewing plugin or skill provenance, and verifying whether hooks or config files introduce implicit trust. The point is not exhaustive documentation for its own sake, but confirming that every preloaded capability is intentional and bounded.
In an agentic environment, one weak link can affect the whole session. A misconfigured connector can surface sensitive context, a permissive tool can create unintended action paths, and a stale configuration can preserve access that should already have been withdrawn. The control objective is to make pre-runtime state as auditable as runtime behaviour.
Where the session depends on external tools or delegated access, prefer clear ownership and explicit policy checks over “known good” assumptions. MCP security is relevant here because the server layer often determines what the agent can invoke before the user sees any evidence of it. AI Agent Authorisation Guide helps translate that setup into least-privilege decisions, while Shadow AI and AI Agent Discovery Guide addresses the inventory side when agents, grants, or connectors exist outside normal visibility.
How do hidden pre-runtime dependencies create real exposure?
Hidden dependencies create exposure by moving trust earlier than the operator expects. If a server or skill is already wired into the session, the agent may inherit access to data sources, actions, or identity context that were never explicitly reapproved for this run. That can create overreach even when the prompt itself looks harmless.
The other failure mode is configuration drift. A setup that was safe last week may no longer be safe if permissions changed, a connector was repointed, or a plugin was updated. In agent systems, drift matters because the preloaded environment can define the agent’s practical authority long before any human reviews the request.
External guidance on agentic control boundaries is also useful because it frames the same issue from a broader security perspective. Zero Trust for AI Agents reinforces the need to verify the principal and request rather than trusting the session by default. For baseline control thinking, NIST Cybersecurity Framework 2.0 supports the govern-then-protect pattern, and NIST Cybersecurity Framework 2.0 is especially useful when you need a simple lifecycle view of inventory, control, and oversight.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Identities and Assets Are Inventoried | The question depends on pre-runtime inventory of attached agent components. |
| GV.PO-01 — Policy Establishes Cybersecurity Governance | Pre-runtime trust decisions require policy-defined boundaries and approval rules. | |
| Recommendation — Inventory every attached server, skill, hook, and connector before enabling the session. Define policy for which agent components may be approved, connected, and reused. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Configuration drift and hidden dependencies are fundamentally inventory and baselining problems. |
| AC-6 — Least Privilege | Preloaded tools and connectors can expand authority unless bounded to minimum access. | |
| Recommendation — Maintain an authoritative inventory of agent-related components and their approved states. Limit each attached component to the minimum access needed for its approved role. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent setup can pre-authorize excessive or misbound authority before runtime begins. |
| Recommendation — Review attached identities and privileges before the agent is allowed to act. | ||
Practitioner Guidance
What to prioritise: Treat pre-runtime inventory as the gate, not a documentation exercise. If the agent can inherit a tool, a server, or a secret-like capability, verify that it is approved for this specific environment before the session is allowed to start.
What to verify: Confirm which components are attached, which identities or tokens they rely on, and whether any connector or hook changes the agent’s effective authority. If that cannot be stated clearly, the setup is not ready for production use.
Common mistake: Teams often harden the prompt while leaving the surrounding agent environment loosely controlled. That reverses the real risk order, because the first exposure is often inherited from configuration, not generated by model output.
Practitioner takeaway: For Claude agents, governance begins with the session shape, not the first response, so the right control question is whether the attached environment is already safe to trust.