Securing AI agents and MCP servers in production · Daniel Tinizaray

AI agents are no longer lab demos. Today they run automation, call corporate APIs, read databases and trigger deployments. That turns every agent into an attack surface the traditional perimeter does not cover. This is the checklist I use to bring them to production without handing the model the master key.

The problem: the agent inherits every permission

A typical agent architecture chains an LLM, an orchestration framework, a collection of tools (via MCP or other transports) and the target systems. The risk grows because authority travels across the whole chain and the model decides when to invoke each tool based on context, not on real privileges.

LLM Agent → Orchestrator → Tools (MCP) → API, DB, CI/CD

If an internal tool has broad permissions and the model context gets poisoned (prompt injection), the agent can execute a legitimate action with malicious data. The result: sensitive context leakage or unintended downstream tools being activated.

Hardening checklist

• Least privilege per tool: each tool exposes the smallest possible surface of actions, scoped by resource and by user.
• Explicit authentication: use OAuth 2.1 for remote MCP servers and short-lived tokens; never embed long-lived credentials.
• Propagated task validation: an MCP server must validate the origin, scope and intent of each incoming task before forwarding it to another component.
• Sandboxing: each server runs isolated in its own container, with egress allowlists and URL scheme validation to stop SSRF.
• Fail-closed: if an MCP server goes down, the predefined behavior must be safe and tested before production.

Modeling trust: zero-trust for agents

An agent is not an implicitly trusted user. Treat it as another process in your service mesh: its own identity, minimal policy, auditable logs and rate limits. When two agents talk, every message should carry verifiable context about who emitted it and what authority it holds.

// Conceptual authorization layer per tool
{
  "tool": "deploy_production",
  "allowed_identities": ["orchestrator-cd"],
  "max_rate_per_hour": 4,
  "required_approval": true,
  "deny_by_default": true
}

Observability of the happy path and the hostile one

Application logs are not enough. For agents you need a record of the full chain: what prompt entered, what tools were invoked, with which parameters and what they affected. That lets you detect anomalies like an agent calling a production tool out of hours or with an unusual payload.

• Trace the propagation of tasks across MCP servers.
• Alert on denied access attempts, not just on failures.
• Retain enough audit context to reconstruct an incident.

Conclusion

Agent security is not a plugin you install; it is a default practice. Explicit authentication, least privilege, sandboxing and task validation turn an agent from a risk into a controlled tool. The model can be brilliant; you decide how much it may touch.