From AI That Talks
to AI That Acts
For two years, enterprise AI security asked one question: what did an employee type into the chat box? As MCP and agents spread, the question is changing: what did the AI do inside our systems?
This is not a product page. It sets out how FlowGuard AI reads this shift, and what enterprises should be checking now.
The Control Point Has Moved Three Times
Each wave stacks on the last rather than replacing it. The problem is that most security programs are still built for the first.
AI That Read and Replied
An employee pastes something into a chat box and gets an answer. The risk was one thing — what was typed — and the control point was a single input box.
Control point · the promptAI That Connects
Through MCP, AI connects directly to internal wikis, databases, ticketing systems, and code repositories. The AI retrieves data on its own, even when no one typed anything.
Control point · connections and scopesAI That Acts
Agents decide and invoke tools on their own — closing tickets, changing settings, sending mail, committing code. The risk is no longer what was said, but what was done.
Control point · tool calls and actionsWhat Prompt Inspection Cannot See
In the scenario below, the employee typed no sensitive data at all.
- 1An employee asks the agent: "summarize why customers churned last week."
- 2The agent reaches the customer database over MCP and reads real customer records.
- 3It summarizes what it read and creates a document in a public channel of an external collaboration tool.
- 4The prompt DLP log shows no violation — the input was an ordinary work request.
The exposure happened in the action, not the input. The control belongs between "read the customer database" and "write to an external public channel" — not at the prompt.
5 Risks in an MCP Environment
These are not flaws in the protocol — they are structural risks that appear as connections multiply.
Hidden instructions embedded in the tool descriptions an MCP server advertises can steer agent behavior. To the user, the tool looks entirely normal.
Text planted in a document, ticket, or issue the agent reads gets interpreted as an instruction. The attacker never needs to touch the AI directly.
Broad tokens issued for integration convenience leave the agent with standing access to systems it never needs for the task at hand.
Internal data read by one tool leaves through another. Each call looks legitimate on its own; chained together they form an exfiltration path.
Without a record of which tools an agent invoked, with what arguments, and what changed, neither post-incident analysis nor regulatory response is possible.
The Three Layers of AI Guardrails
Guardrails are not one feature but three layers. The third is where the agent era is actually decided.
Input Guardrails
— What people and systems feed the AIInspect sensitive data, injection patterns, and policy-violating requests before they reach the model. This is where most of today's "AI security" stops.
Well establishedOutput Guardrails
— What the AI returns to peopleInspect responses for sensitive data, internal credentials, and inappropriate or ungrounded content. It matters more as RAG and internal knowledge integrations grow.
EmergingAction Guardrails
— What the AI actually does to systemsInspect the tool and arguments an agent is about to invoke, right before execution — which MCP server it is connected to, under what scope, doing what to which target. Irreversible actions get routed to approval.
Least mature — the widest gap6 Things to Check Now
Vendor-neutral questions any organization adopting agents should be able to answer.
Without visibility, no other control holds. Servers wired up by individual developers are the most common blind spot.
"Open it wide now, narrow it later" almost never gets narrowed. Issuance is the only real control point.
This is the core defense against indirect prompt injection. Text inside documents, tickets, or web responses must never change policy.
Deletions, transmissions, payments, and permission changes are hard to undo. The line between automated and approved must be written down.
Both regulators and incident investigations ask who initiated it and what the agent did. Conversation logs alone are not enough.
This precedes any technical control. If no team owns incidents an agent causes, the controls will not be operated either.
Where FlowGuard AI Stands
We state plainly what ships today and where we are heading.
- Endpoint-based visibility into AI usage — which tools, used where
- Sensitive data detection and blocking in prompts and responses
- Shadow AI discovery, including AI code assistants
- Policy-based control and audit logging per organization
- MCP connection visibility — which agents are wired to which systems
- Tool-call-level policy checks and action guardrails
- Indirect prompt injection detection
- Agent action audit trails and approval workflows
These are directions in development, not features in the current product. Contact us for timelines and scope.