Preventing Tool Exploitation: Centralizing Policy Across Repositories, APIs, and MCP Servers

Date: 13 November 2026

Executive Summary

AI systems increasingly act through tools that read repositories, call APIs, execute workflows, and access MCP servers. Each tool expands the system’s authority and creates another location where an attacker, compromised identity, malicious instruction, or policy mistake can produce unauthorized impact.

The business risk is not limited to prompt injection. The larger problem is fragmented control: one service validates identity, another interprets permissions, and a third records incomplete logs. Security teams should make a deliberate architectural decision to centralize authorization policy and policy evaluation while keeping enforcement close to each tool boundary.

Centralization does not mean giving one component unrestricted control. It means establishing consistent decisions, policy vocabulary, audit requirements, and failure behavior across repositories, APIs, and MCP servers.

Architecture and Threat Model
Separating the Core Security Controls
A Controlled Tool-Call Flow
Implementation Guidance
Risks and Mitigations
Deployment Checklist
Frequently Asked Questions

Architecture and Threat Model

A tool-using AI application typically contains an orchestration layer, a model, tool adapters, policy services, identity providers, and target systems. The target systems may include source repositories, ticketing systems, cloud APIs, databases, internal services, and MCP servers exposing several tools through a common protocol.

Every connection between these components should be treated as a trust boundary. A model output is not a security decision. A tool description is not an authorization grant. An MCP server is not automatically trusted because it runs inside a private network.

Trust Boundaries

Untrusted input to model: User prompts, retrieved documents, issue descriptions, web content, and repository files may contain instructions designed to manipulate tool use.
Model to orchestrator: The model proposes an action, but the orchestrator must validate the requested tool, arguments, identity, purpose, and context.
Orchestrator to tool adapter: The adapter translates an abstract request into an API call. This is a high-risk boundary because argument transformation can introduce privilege or data-loss errors.
Tool adapter to target system: The target API must enforce its own permissions. Central policy should not be treated as a replacement for native controls.
MCP client to MCP server: The server exposes capabilities and may access additional systems. Its tools, schemas, credentials, and returned content require independent validation.

Threats

A threat model should cover both malicious behavior and ordinary failure. Relevant scenarios include prompt injection in a repository file, a confused-deputy attack where the AI uses a powerful service identity for a weaker user, replay of an approved tool request, manipulation of tool arguments, excessive permissions, compromised MCP servers, leaked credentials, and incomplete audit trails.

Availability failures also matter. A policy service timeout, stale identity claim, unavailable repository, or malformed tool response can cause either unsafe fail-open behavior or excessive operational disruption. These outcomes should be designed rather than left to library defaults.

Separating the Core Security Controls

Authentication

Authentication establishes who or what is making a request. It may identify a human user, workload, agent instance, tool adapter, MCP server, or downstream service. Authentication alone does not establish what the requester may do.

For agentic systems, preserve identity context across hops. A downstream API should be able to distinguish the end user, the orchestrating application, and the specific agent or workflow instance. Do not replace this context with a single shared service account unless the resulting loss of accountability is an explicit and accepted decision.

Authorization

Authorization determines whether an authenticated principal may perform a particular action on a particular resource under particular conditions. Useful decision inputs include user identity, workload identity, repository or tenant, requested operation, resource sensitivity, environment, tool risk, approval state, and time.

Authorization should be evaluated against the actual action, not only the tool name. A generic “repository tool” could read a public file, modify production deployment configuration, or delete branches. These actions need different permissions.

Policy Enforcement

Policy enforcement prevents an unauthorized action from reaching its target. A centralized decision service may return allow, deny, or require approval, but enforcement must occur at a boundary the caller cannot bypass. For example, a policy decision made in the orchestrator is insufficient if the MCP server can be called directly with a different client.

Use layered enforcement: the orchestrator validates intent, the adapter validates schemas and arguments, the MCP server applies capability restrictions, and the target API applies native authorization.

Auditability

Auditability makes security decisions reconstructable. Logs should record the request identifier, principal chain, tool and server identity, resource, operation, policy version, decision, reason, approval reference, timestamp, result status, and relevant data classification.

Audit logs should not automatically contain full prompts, secrets, tokens, or sensitive repository contents. Define retention, access, redaction, integrity, and correlation rules according to the organization’s risk and applicable obligations. Do not assume that a particular retention period is universally required.

A Controlled Tool-Call Flow

A secure flow treats a model-generated tool call as an untrusted proposal:

The user or workflow submits a request.
The model proposes a tool and arguments.
The orchestrator validates that the tool is registered and that the arguments match its schema.
The orchestrator creates a canonical action containing the principal, operation, resource, purpose, and context.
The policy service evaluates the action against centralized policy.
The enforcement point applies the decision, requiring human approval or a narrower capability when necessary.
The adapter sends a bounded request using an appropriately scoped credential.
The response is validated, classified, and recorded before it is returned to the model.

Illustrative example: A model asks an MCP server to “update the deployment configuration.” The canonical action should identify the exact repository, branch, file path, proposed change, environment, initiating user, and workflow. A policy may allow a pull request in a development repository, require approval for a production repository, and deny direct modification of protected deployment files.

{
  "principal": {
    "user": "user-123",
    "workload": "agent-orchestrator",
    "session": "session-456"
  },
  "action": "repository.file.update",
  "resource": "repo:payments/deployment.yaml",
  "environment": "production",
  "purpose": "proposed configuration change",
  "tool": "mcp-repository-server",
  "policy_context": {
    "approval": "required",
    "change_id": "change-789"
  }
}

Implementation Guidance

Use a Canonical Policy Model

Repositories, APIs, and MCP servers often describe permissions differently. Normalize them into a common model with principal, action, resource, conditions, decision, and obligations. Obligations may include redaction, approval, rate limits, read-only mode, or mandatory logging.

Illustrative policy:

policy "production_deployment_change" {
  when action == "deployment.config.update"
    and environment == "production"
  then require_approval("production-owner")
       require_change_record()
       deny_direct_execution()
}

The syntax above is illustrative, not a claim about a specific policy language or standard. In production, define how policies are versioned, tested, reviewed, deployed, and rolled back.

Constrain Tools and Arguments

Register tools explicitly. Record the server that owns each tool, the permitted data classifications, supported operations, argument schema, maximum result size, and required approval level. Reject unknown tools and unknown arguments rather than passing them through.

Use allowlists for repositories, API methods, hosts, paths, and environments. Normalize paths before checking them. Prevent path traversal, ambiguous resource identifiers, shell metacharacters, and cross-tenant references. Treat tool output as untrusted data when it is returned to the model.

Apply Least Privilege at Each Hop

Use separate credentials for read, write, administrative, and deployment operations. Prefer short-lived credentials with audience restrictions and narrow scopes. A central policy decision should reduce the requested capability before execution, not merely approve an all-powerful credential.

Design Failure Behavior

High-impact mutations should fail closed when policy cannot be evaluated. Low-risk read operations may use a documented degraded mode if the data classification and exposure are acceptable. Every exception should be explicit, time-limited, monitored, and tested.

Prevent replay by binding approvals and decisions to a canonical action, request identifier, policy version, expiration time, and target resource. A decision for one file or environment must not be reusable for another.

Make Observability Actionable

Correlate model request, policy decision, downstream request, approval, and result with a shared identifier. Alert on denied-action spikes, new tools, policy bypass attempts, unusual resource access, repeated approval failures, direct MCP access, and changes to tool registration.

Log both successful and denied actions. A system that records only executed requests cannot show whether an attack was attempted or whether controls worked.

Risks and Mitigations

Risk	Likely Failure	Mitigation
Prompt injection	Untrusted content causes an unauthorized tool request	Separate content from instructions; validate every action independently
Confused deputy	A powerful service identity acts beyond the user’s authority	Preserve user context and enforce delegated authorization at the target boundary
Policy drift	Repositories and APIs enforce inconsistent rules	Use a central policy model, versioning, testing, and policy ownership
MCP compromise	A server exposes unexpected tools or forwards data improperly	Register servers, pin capabilities, isolate credentials, and monitor tool changes
Fail-open behavior	Policy outage permits unsafe execution	Define risk-based failure modes and test outages explicitly
Weak audit trail	Security teams cannot reconstruct who did what and why	Correlate identity, action, policy, approval, result, and policy version

Deployment Checklist

Inventory every repository, API, MCP server, tool, credential, and execution path.
Document trust boundaries and identify which component enforces each control.
Define a canonical action model for read, write, delete, execute, and administrative operations.
Separate authentication, authorization, enforcement, and audit responsibilities.
Register tools explicitly and validate schemas, paths, hosts, resources, and environments.
Use scoped, short-lived credentials and preserve the principal chain across service hops.
Centralize policy decisions, policy versions, approval requirements, and reason codes.
Set fail-closed or degraded behavior by risk category, not by convenience.
Test prompt injection, confused-deputy attacks, replay, policy outages, and direct-server bypasses.
Monitor denied actions, new capabilities, unusual access, and policy changes.
Review policy effectiveness after incidents, near misses, and material architecture changes.

Frequently Asked Questions

Does centralized policy replace permissions in repositories and APIs?

No. Central policy coordinates decisions and consistency. Native repository and API permissions remain an important independent enforcement layer.

Should every tool call require human approval?

No. Approval should be based on impact, sensitivity, reversibility, and confidence in the authorization context. Low-risk reads may be automated, while destructive or production actions may require approval.

Is an MCP server trusted if it is internal?

No. Network location does not establish trust. Authenticate the server, inventory its tools, restrict its credentials, validate its outputs, and monitor changes.

Can the model perform authorization?

The model can help interpret intent, but it should not be the final authorization authority. Deterministic enforcement must evaluate the canonical action outside the model.

What should be logged?

Log the principal chain, action, resource, tool, server, policy version, decision, reason, approval, timestamp, and result. Redact secrets and avoid unnecessary sensitive content.

How should policy outages be handled?

Define behavior by risk. High-impact mutations should normally stop when policy cannot be evaluated. Any degraded read mode should be narrow, documented, monitored, and periodically tested.

Is a single policy service always the right architecture?

Not necessarily. A federated model may be appropriate for separate tenants, regions, or operational domains. The essential requirement is consistent semantics, explicit ownership, and enforcement that cannot be bypassed.

AXEC governs AI agent access with identity, runtime authorization, and audit trails

Use AXEC for governed AI-agent security and schedule a 30-minute meeting to discuss your agentic workflow controls.