The agent now has tools
Model Context Protocol, MCP servers, and similar connectors changed the workflow: the agent no longer just suggests text. It can call tools, read context, open issues, query docs, browse, run tests, and edit files. For productivity, that is excellent. For security, it creates a new boundary.
The risk is not "MCP is bad". The risk is approving a tool without understanding that it can read sensitive data, execute commands, publish information, or combine actions to exfiltrate context.
Questions that matter
- Which tools can the agent call?
- Can they read files, secrets, databases, issues, analytics, or email?
- Is there manual approval for sensitive actions?
- Is configuration global or project-scoped?
- Did the MCP server come from a trustworthy source?
- Do logs show which tool was used and why?
- Can the agent use unrestricted network or commands?
Where AI SaaS should review
The critical point is any agent connected to production, support, CRM, payments, storage, logs, private repositories, or environments with secrets. Indirect prompt injection in a document, ticket, or page can try to make the tool do something outside the intended flow.
A healthy path
Start with read-only. Then grant tools by least privilege. Require confirmation for writes, deploys, commands, network access, exports, and configuration changes. Review AGENTS.md, project rules, mcp.json, IDE permissions, and secrets before treating the agent as autonomous teammate.
An agent with tools is a system with permissions. Systems with permissions need scope, logs, and limits.
