Data & AI platform by Data Analytics
Using MCP with explicit boundaries and control
MCP provides a way to connect suitable AI clients with context and tools. The protocol does not automatically make your data or actions secure. You must determine which component trusts which information, what permissions apply and who handles anomalies. ENABLE is the manageable Data & AI platform from Data Analytics for business data, analysis, apps and AI. An MCP setup on that foundation requires additional measures for each application. Control means demonstrable checks and ongoing maintenance, not a promise that data can never leak or a model can never make a mistake.
The examples on this page are hypothetical situations, not customer cases.
Meet our team
Trusted by data-driven organisations
01
Map trust boundaries before connecting
Map the user, client, language model, MCP server and underlying data sources separately. Describe where identity is established, where tokens go and where data leaves the organisation. A client must not decide for itself that another business entity is accessible. The server must check every request against trusted identity information and the applicable authorisation policy.
Explicitly choose whether selected data may be sent to an external LLM. Check contracts, settings, processing locations and retention periods for that route. Your own server does not guarantee internal model processing. Limit outgoing fields and protect secrets. Store credentials in purpose-built facilities; do not put them in prompts, tool descriptions or unprotected configuration files.
02
Treat tool results as untrusted input
A retrieved document may contain instructions that try to divert the model from its task. This is prompt injection: source content is incorrectly treated as an authoritative instruction. A tool result, error message or external page can contain such text too. Do not let this content expand access rights, request secrets or establish new execution rules.
Separate instructions from source content as clearly as possible, restrict available tools and validate calls outside the model. Filtering and detection can help, but do not fully solve prompt injection. Explicitly test misleading documents and unexpected tool output. Hypothetical example: an invoice note asks for customer data to be sent to an external destination; server policy must block that action.
03
Technically enforce read-only access and least privilege
If you allow reading only, enforce that restriction on the server and in the database or underlying API permissions. Use restricted accounts, views and row filters where appropriate. A tool named “read” is insufficient if its database user can also write. Also verify that an alternative tool cannot bypass the restriction.
Grant scopes per task and dataset, rather than default access to the entire platform. Validate parameters, bound results and prevent arbitrary SQL or file access. Assess indirect effects of apparently read-only tools too. Test denied access with different roles and business entities, and check that error messages do not reveal sensitive information about other users.
04
Keep writing separate, with approval and recovery
Design write capabilities as separate tools with separate scopes and server policies. Show the specific change, affected records and expected effects before an authorised employee explicitly approves. Bind the approval to that action and its parameters. General consent at the start of a conversation must not silently authorise all later changes.
Recheck permission at execution and reject expired or altered requests. Use idempotency keys where appropriate to prevent duplicate execution after a retry. Define rollback or a compensation procedure, including situations where reversal is impossible. Test partial failure and recovery. Human approval does not replace technical validation or transaction rules.
05
Log minimally and organise ongoing assessment
For accountability, record who used which tool, within what scope, with what outcome and any approval. Do not automatically collect full prompts, personal data or every tool result. Minimise and mask where possible. Protect audit logs with restricted access and integrity measures, agree an appropriate retention period and arrange deletion when it expires.
Assign owners for key management, updates, incidents and periodic access reviews. Practise revoking tokens, disabling tools and informing users. Repeat acceptance tests after changes to the client, server, model or source. Data Analytics can help define the measures needed around ENABLE; residual risk always requires a deliberate organisational assessment.
Frequently asked questions
Does MCP automatically secure a connection?
No. The protocol does not replace authentication, authorisation, data minimisation or management. The chosen client, server, data source and model service together form the route you must assess and test.
Is an instruction not to change anything sufficient?
No. Read-only access must be enforced at server level and in database or API permissions. Also restrict alternative tools and check that indirect write effects are not possible.
Must every conversation be logged?
Not by default. Determine which audit data is necessary, minimise content and protect the logs. Agree access, retention and deletion; extensive logging can itself pose privacy and security risks.
Does filtering eliminate prompt injection?
No. Filtering can help, but tool output remains untrusted. Combine bounded tools, technical authorisation, execution validation and testing. Never let source content independently determine which powers a model receives.
Technical documentation
Discuss your question with Data Analytics
Which sources, users and checks does your application need? Discuss your question in an ENABLE demo.
Meet our team