When a team asks an assistant to check orders, I first ask which orders it should be allowed to see. The connection is only part of the work. Access and the shape of the answer need a decision too.
MCP provides a common interface for tools. My first release is a narrow set of queries. Writes come later, after the team has checked the read behaviour.
What the roadmap does and does not promise
The maintainers’ post of 22 August 2026 describes five priority areas. Agent identity and enterprise security are among them, with work on DPoP, workload identity and token exchange. Progressive tool discovery is another planned effort.
The post also describes the July 2026 release as making remote servers easier to operate as ordinary HTTP services. I take that as a reason to apply ordinary service controls: authenticate callers, authorise operations, record outcomes and make access revocable. The roadmap does not give those controls to an integration automatically.
Why reading still needs boundaries
Invariant Labs’ April 2025 research demonstrated instructions hidden in tool descriptions. An assistant could follow them while appearing to perform the requested calculation. That is a prompt-injection problem, even if the advertised tool sounds harmless.
A read-only server also sees data. It can disclose too much, return an injected instruction or expose credentials available to its process. Giving the backend a read-only credential reduces unwanted changes through that credential. It does not make the assistant or server safe by itself.
CSA recommends a gradual increase in trust, starting with limited read access and oversight. I use that as deployment guidance, not as a security guarantee.
The first build
I agree a short tool catalogue with the team:
- One question per tool. Stock by product, orders by status or an approved policy lookup.
- Permissions enforced at the source. The caller sees only authorised records and fields. Write attempts must fail.
- Reviewed server code and configuration. The process gets only the credentials and file access it needs.
- A useful audit log. Caller, tool, time, outcome and a safe reference to the result. I redact secrets and personal data instead of recording every payload.
- Reviewed connections. Approved servers and tool definitions, with changes checked before use.
I test wrong-account access, excessive queries and injected content as well as normal answers. A successful answer is only one acceptance check.
Adding writes
A tool that prepares an invoice and a tool that sends it are separate actions. I give each the permissions it needs and ask a person to approve the actual target and action in the first version.
The log records what changed and who approved it. Retry behaviour and recovery need a design before release. This is the same approach I describe in AI request processing with human review.
I can build this with you
The deliverable is a small tool catalogue with tested access boundaries, an audit trail and an agreed path for adding writes. The situation page is a custom MCP server; the service is API integrations and automation. If the task is clear, I can quote the implementation directly.
