Connect your agents. Control what they can do.

Expose an approved operation, not a whole system

An MCP server can wrap selected business APIs as named tools. An agent acting through an MCP client can discover and call those tools. Your CRM, accounting platform or internal application keeps its existing business rules. The server controls what the caller can do, even when the model asks for something else.

Start with a narrow job such as finding an order status or preparing a service request. Define the accepted inputs, returned fields and permitted users. Avoid generic tools that execute arbitrary SQL, call any URL or make unrestricted changes. A read-only label in a tool description is not an access control.

Read order status

Order reference

Return only records and fields the caller may access.

Prepare a CRM update

Record ID and proposed changes

Validate the fields and show a draft without writing.

Apply an approved update

Approved change and record version

Check approval, current permissions and duplicate execution before committing.

Check identity at every boundary

For a remote HTTP deployment, design the authorisation flow around the supported MCP specification and your identity provider. Validate the intended token audience and required scopes. Keep downstream API credentials on the server rather than passing the client token through to another service.

Scope every call to the correct person, organisation and record. A tool appearing in the catalogue does not authorise its execution. Apply checks again when the operation runs, including after an approval delay. An approval should refer to the actual change and its version so later edits cannot silently reuse it.

Prove that unsafe calls stop and retries stay safe

Treat retrieved documents and tool output as untrusted data. Test whether hostile instructions can trigger another tool, reveal a restricted record or redirect a request. Restrict outbound destinations, limit request size and execution time, and apply per-user and per-organisation rate limits.

Rehearse revoked access, stale approvals, a provider outage and an interrupted write. Use idempotency and reconciliation where the underlying operation supports them. Keep an audit record of the requester, tool, authorisation result and outcome without logging secrets. Give the operating team a way to disable a tool and investigate a failed call.

The first release should demonstrate one complete business task. Broader access comes after the organisation has evidence that the boundary holds and knows who owns the recovery process.