Agents let business users specify goals in natural language, but their behavior cannot be predicted as reliably as statically written software.
2
MCP introduces supply-chain, third-party data, and unintended agent behavior risks because servers can change, expose unexpected data, and influence model actions.
3
Enterprises can reduce exposure with monitoring gateways, local hooks, approved MCP catalogs, and role-based permissions at the tool and data level.
Summary
Jiquan Ngiam describes the move from software written line by line to agents that interpret instructions, choose tools, and work toward goals. This gives business users more freedom, but it also makes behavior harder to predict. MCP increases the risk because servers can change their tools, connect systems that were previously separate, and place instructions or sensitive data into an agent's context. Ngiam groups the risks into supply-chain problems, third-party data exposure, and agents performing harmful actions while trying to be helpful. His proposed controls include gateways that inspect tool calls and responses, hooks that block sensitive file access locally, approved MCP catalogs, and permissions based on roles, tools, and data. He argues that enterprises should mediate access rather than let every agent connect directly to every MCP server. The talk includes examples involving leaked email copies, environment files, cloud secrets, and overly broad GitHub permissions.
Agents turn programming into goal-directed work for business users
Ngiam describes a shift from static programs, where developers determine how every line operates, to dynamic programs driven by prompts and instructions. An agent receives a goal in natural language, decides which tools to call, and works out how to complete the task. This lets business users specify logic without writing traditional code. The flexibility also removes much of the predictability that came from statically analyzing code paths. Ngiam calls the change a dual-edged sword: agents can handle difficult tasks such as collecting and analyzing data, but users cannot know in advance exactly what the agent will do.
MCP makes tool access flexible while removing guarantees about future behavior
MCP servers can gain new capabilities without changes to the agent using them. Ngiam says this is useful because an agent can adapt when a vendor adds tools. The same property creates risk. A previously acceptable server could later add operations such as deleting a repository or user group. He uses a hypothetical GitHub server to show why a new destructive function may appear without users intending to grant that access. The agent may then see and use the new capability. Enterprises therefore need to consider changes to MCP tools over time, rather than treating approval as permanent.
MCP connects systems easily, which also makes unwanted data movement easier
Ngiam contrasts the old difficulty of joining Google Analytics, marketing, sales, and internal data with the ease of connecting MCP servers for each source. Agents can correlate information across systems with natural language instructions. The same connections can enable data exfiltration. He describes an Okta MCP used alongside a Twitter or Reddit MCP as a risky combination because HR data could be pushed to an external system. Natural-language instructions add another attack surface through prompt injection. A user may ask for an ordinary task while content entering the agent causes it to send information somewhere the organization did not intend.
MCP supply-chain risk starts with choosing a server and continues after installation
Ngiam shows how MCP registries make server selection difficult. He cites directories listing thousands of servers and describes finding several similarly named SEO servers across registries, with unclear security badges and ownership. He then gives an example of an unofficial Postmark MCP server that looked legitimate in the npm registry. Its author later added one line that BCCed every email sent through the server to the attacker's address. Ngiam calls this a rockpool attack: a server appears trustworthy at first, then its implementation changes. Installing an MCP can give both the server and its author control over the agent, and local installation can also give the code control of the user's computer.
Trusted MCP servers can still return data and instructions that change agent behavior
Ngiam presents a proof of concept using Claude Code and a documentation MCP with feedback functions. A feedback response included sensitive-looking values such as OpenAI and Google keys, along with instructions asking the agent to provide more information for an enterprise IT team. These tool outputs were easy to miss because the agent moved quickly and hid some details behind a shortcut. The example shows that trusting the MCP author is not enough. Teams also need to examine what data enters the MCP and what content comes back in tool responses, since that content can instruct the agent to exfiltrate information.
Helpful agents may read and send secrets without malicious intent
Ngiam says agents are trained to be helpful, so an instruction such as reading environment files may cause them to retrieve keys and potentially send them elsewhere. The agent does not need to be deliberately malicious for this to happen. It is following the apparent task while crossing a boundary that an enterprise may care about. He groups this with supply-chain risk and third-party data risk as one of three areas enterprises should address. Production deployments need controls around secrets and sensitive files because an agent's willingness to act can itself produce unwanted behavior.
Gateways give enterprises visibility and a place to block tool calls
Ngiam argues that organizations cannot govern agent activity they cannot see. His proposed gateway sits between an agent such as Claude Code and the language-model provider. It observes tool calls and tool responses, applies rules, and presents the agent with revised messages. In his demonstration, a rule blocked Claude from reading files containing '.env'. The agent tried again but still could not access them. Ngiam says production monitoring commonly finds attempts to read environment files, run sudo commands, and retrieve secrets from Kubernetes or Google Cloud. A gateway can also add secret or PII filters and record activity for investigation.
Local hooks can stop sensitive actions before an agent performs them
Ngiam presents hooks as a second control point. In Cursor, hooks can run before reading a file or submitting a prompt. His example installs hooks that scan files for secrets and tell Cursor not to read files containing them. The hooks block the conversation from continuing when the agent attempts the sensitive action, and they show when each hook is triggered. In the question period, he explains that detection should combine file names with content screening. Patterns such as AWS keys beginning with 'AKIA' and entropy-based checks can identify secrets. He recommends running content scans locally so the material does not leave the machine.
Secure deployment requires approved catalogs and permissions at tool level
Ngiam recommends that organizations maintain a catalog of approved MCP servers rather than letting users connect anything they find. He also argues that permissions should be defined at the tool and data level. A broad GitHub server may include tools for deleting files or project items, even when a user only needs to inspect pull requests. In his role-based model, engineers might access Jira, GitHub, and selected Snowflake data, while sales users would not need GitHub. Finance might receive access to different Snowflake tables. MCP gateways can mediate these connections and expose only the tools and data allowed for each role.
"We used to be able to statically analyze code to figure out all the code paths and what the agent might do. But now in this new world, we have no idea what's going to happen."02:36
Who should watch
You are evaluating MCP servers for internal data, developer tools, or business workflows and need a way to assess the risks before adoption.
Your organization allows Claude Code, Cursor, Codex, or other agents to access files, cloud services, or source-control systems.
You need practical controls for monitoring tool calls, blocking secret access, and assigning MCP permissions to teams and individual roles.
