MCP Security and Runtime Policy Enforcement
Model Context Protocol (MCP) is an open standard, originally published by Anthropic, that defines how AI applications connect to external tools and data sources through standardized client-server interactions. The specification defines distinct roles for hosts, clients, and servers, along with mechanisms for tool discovery, tool invocation, and resource access that a server must explicitly expose. Importantly, MCP does not mandate a specific authentication mechanism; its own security guidance states that servers are responsible for implementing authorization and access control. This means capability exposure (what a tool can do) and authorization (who is allowed to invoke it) are separate concerns that must be governed independently.
Runtime enforcement closes that gap: rather than granting broad access at initial connection or session setup, each individual tool call is validated against policy immediately before execution. For research discovery systems, a single agent connection might legitimately need to search a catalog but should not automatically be permitted to pull bulk records from a licensed database or query a patron's account history without separate, explicit authorization.
Implementing Least-Privilege and Tool-Call Governance
- Inventory agentic touchpoints: Map every AI-driven component (discovery layer, chat assistant, recommendation engine) and the specific tool calls each one issues to catalogs, databases, repositories, or patron systems.
- Establish agent identity: Assign each agent a verifiable identity distinct from the end user it is acting on behalf of, and require that identity on every tool call.
- Define per-source access policy: Set access rules per data source that reflect license terms and patron privacy requirements, since these will differ by vendor and content type.
- Deploy runtime enforcement: Place a policy enforcement point between the agent and the tool-calling layer so every call is evaluated before execution, not just at session start.
- Centralize policy management: Manage access policies centrally rather than embedding rules in individual integrations, to keep enforcement consistent as new AI features are added.
- Capture call-level audit logs: Log agent identity, invoked tool, parameters, and data scope for every access, in a form that can be exported for license or privacy review.
Governance, Licensing, and Compliance Considerations
AI agents that access patron records or borrowing history intersect with patron privacy principles and, in academic settings, may intersect with student-record privacy obligations, which makes explicit scoping of what an agent may retrieve a governance requirement rather than an optional control. Licensing agreements with database vendors commonly restrict redistribution, bulk extraction, or use of licensed content for purposes such as AI training, and these boundaries need to be enforced at the tool-call level rather than assumed through policy documents alone.
Demonstrating compliance during a vendor license audit or institutional privacy review generally requires activity-level evidence of what an agent accessed and why, not static configuration records. Frameworks such as the NIST AI Risk Management Framework, organized around Govern, Map, Measure, and Manage functions, provide a structure for identifying and mitigating AI-related risk, but they do not specify library- or research-sector controls directly. Institutions have to translate that general structure into sector-specific policy, accounting for the fact that licensing terms and privacy obligations vary across vendors and cannot be enforced with a single uniform rule set.