By Securelay Research
Blocking a chatbot does not govern the AI data path.
Sensitive data can reach AI through IDE assistants, retrieval pipelines, MCP tools, internal agents, support workflows, and model APIs. A web-domain block sees only one route. Runtime AI governance begins with the complete data path.
Inventory execution paths, not just models
List the applications and people that can invoke AI, the tools and data stores each workflow can reach, the model destinations, the purpose of use, and the identity under which the action runs. NIST’s Generative AI Profile frames risk work across govern, map, measure, and manage; a usable inventory connects those functions to actual data movement.
Protect sensitive values before a configured provider
On routes integrated with Securelay, configured sensitive classes can be detected and transformed before the model connection receives them. Stable protected references preserve useful structure for selected workflows while the source values stay behind the governed boundary. Detection and transformation coverage must be tested against the organization’s own data and languages.
Treat rehydration as disclosure
Putting a protected value back into an application response should evaluate the current role, purpose, consent, scope, and operational limits. Permit and deny outcomes should both leave value-free evidence. This makes the data decision reviewable without writing the underlying sensitive value into the receipt.
Close bypass routes with companion controls
Securelay does not control traffic that routes around it, choose the model, sandbox agent tools, or solve prompt injection. Network egress policy, workload identity, tool permissions, endpoint controls, model governance, and human review remain necessary. The practical goal is a tested boundary around named workflows—not a universal claim about every AI interaction.