Security gateway for AI-agent actions
Castling enforces policies on agent tool calls and applies configured PII masking to selected personal data in traffic routed through its gateway—outside the agent’s own decision logic.
Castling gatewayContext changes the question
Sending a message may be routine. Sending it to a new external destination, with an unusual number of recipients, after a large customer-data read raises different questions. The action, its parameters and the available context matter together.
Customer data read
Step 1
Archive created
Step 2
External message proposed
Step 3
Illustrative risk scenario, not a live product result. Sequence alone does not prove that the message contains the customer data.
Available controls
Start with a rule your workflow needs: an action to restrict, or selected personal data to mask.
Define which tool actions are allowed on the connected workflow. Test permitted work alongside actions the policy should block.
Mask selected personal data on the connected traffic path. Check that the agent can still complete the task with the masked content.
Illustrative examples. The integration path and supported rules are confirmed for each pilot.
How it works
Castling evaluates tool calls before forwarding them to connected MCP servers. Policy enforcement and configured PII masking apply to traffic routed through the gateway, outside the agent’s own decision logic.
Controls apply to traffic routed through Castling. Other access paths need their own controls.
Deploy in your environment. We’ll confirm deployment needs and integration fit for the selected workflow.
Map one working agent workflow and the tools or data involved.
Choose the actions to restrict or the selected personal data to mask.
Check the selected controls and successful task completion.
Using a different setup? Describe your stack and we’ll check integration fit.
Castling's approach
Castling’s approach looks beyond the tool name to the action’s arguments, relevant behavior and the execution context available on the connected path.
Consider the tool, arguments, destination and magnitude.
Look at relevant prior actions and behavioral patterns without treating sequence alone as proof.
Agree which supported controls, checks or review steps make sense for the workflow.
Unusual behavior is a signal to investigate, not proof of harm.
Pilot program
Bring a working agent workflow. Together, we’ll choose the relevant controls and risk questions, test representative tasks and review the results. Internal tools, customer-facing products and working prototypes are welcome.
What you get
An agreed pilot scope, representative test results and documented limitations.
Pilot scope, timing and commercial terms are agreed together.
FAQ
Together, we’ll choose the controls and scenarios that matter for your workflow. This may include policy enforcement, configured PII masking for selected personal data, and examination of action arguments, behavior or available context where the integration supports it.
No. A working prototype or staging workflow can be a useful starting point. We need representative tasks and someone who can help us test them.
The current integration model is an MCP gateway. Tell us about your agent, tools and deployment needs so we can check compatibility and identify what the pilot can cover.
Existing permissions, sandboxing and checks in code remain essential. Castling adds a policy enforcement point for connected tool calls, so teams can apply and test controls outside the agent’s own logic. A pilot helps determine whether that provides useful additional protection for your workflow.
Scope, timing and commercial terms depend on the workflow and integration. We agree them before the pilot begins.
Discuss a pilot
Tell us which tools or systems it uses. You don’t need to have a security use case defined yet.
Please use a high-level description. Don’t include credentials, customer records or other sensitive data.