Independent research and operating notes on AI agent governance.
Wrkr Series / Post 2 of 4 / Security Architecture
Your MCP Config Is Already Part of Your Security Boundary
An architecture review says the team only "added MCP config." A month later, security is trying to explain why new tool paths are reachable in places nobody modeled. That gap happens because MCP declarations are often treated as convenience plumbing when they are really boundary metadata. If the file can expand what an agent can reach, it belongs in security design, not just developer setup.
Config is not neutral if it changes reach.
In this piece
Implementation context
Wrkr's current repo scope includes MCP server cataloging with
transport, requested permissions, trust overlay, posture notes, and
saved-state projection through wrkr mcp-list. That is
a useful signal because it treats MCP declarations as inventory and
posture data, not as harmless editor decoration.
Where the pressure shows up
Security leaders keep getting the same operational question in different words: what can this agent call right now? The response often drifts to model brand, licensing, or prompt policy. The more useful answer lives in declaration and execution context. MCP entries define discoverable tool paths, transport assumptions, and requested permissions that directly influence boundary reach.
The practical risk is quiet expansion, not dramatic compromise. A file that looked harmless during setup can become the route to internal services, third-party endpoints, or privileged local capabilities. By the time someone notices, the organization is no longer deciding whether to expand the boundary. The boundary already expanded.
This is also where ownership gets blurry. Platform may consider MCP a productivity layer, while AppSec treats reachable tool paths as a control concern. Both views are correct in part. The failure is when neither team owns the full declaration-to-invocation lifecycle.
The failure mode
The anti-pattern is "trust by declaration." Teams review the broad tool choice, skim config shape, and assume runtime use will stay inside that envelope. This keeps early adoption fast, but it mistakes setup metadata for control.
The analogy to earlier platform shifts is direct. API gateways, runners, and deployment environments were once "engineering details" too. They became security topics once they mediated authority. MCP is the same pattern. Declaration completeness, transport choice, and trust assumptions stop being implementation trivia when they shape reachable actions.
The better pattern
The better pattern is layered control. First, inventory MCP declarations as boundary metadata. Second, classify trust and transport posture in the same system you use for repo and workflow posture. Third, feed high-risk declarations into runtime gating where actual invocations can be allowed, blocked, or held for approval.
Wrkr is useful implementation context because it does the first two layers without pretending static inventory solves runtime control. That distinction matters. Discovery reveals edges. Enforcement governs action. Teams that blur the two either overclaim safety or overbuild policy before they have basic visibility.
This framing also improves collaboration language. "Security wants to approve config files" feels like bureaucracy. "We need a deterministic map of declared tool paths and trust posture before we can set selective runtime controls" reads as platform design, because it is.
Why security cares
Unreviewed declarations create capability without governance memory. If security cannot show what was declared, what was requested, and what was approved, every later control conversation gets weaker. That includes audit readiness, incident reconstruction, and executive reporting on exposure.
MCP is also where policy intent meets supply-chain trust. A declaration may look simple while inheriting risk from package source, endpoint trust, pinning discipline, or adjacent permissions. Security cannot make mature risk decisions if that layer stays invisible.
Why platform and engineering care
Platform teams feel this as operability debt. Different machines and repos accumulate different declarations, then behavior diverges in ways that are hard to diagnose quickly. Structured inventory makes those differences explicit before they become debugging emergencies.
It also clarifies investment sequencing. Discovery should land first and stay cheap. Runtime control should be selective and focused on high-consequence paths. That balance protects throughput while still improving control quality.
What to do next
- Pick one business-critical engineering group and collect all MCP declarations across local and repo scopes.
- Capture transport, requested permissions, trust assumptions, and parse confidence as first-class fields.
- Separate approved, known-unapproved, and unknown-to-security declarations in the same view.
- Identify which declarations need runtime gating now versus inventory-only monitoring.
- Review this output jointly between AppSec and platform, then set a two-week drift check cadence.
If that process feels heavier than expected, it is usually because MCP has already become part of production-adjacent infrastructure. That is exactly why the next blind spot is CI.