Consulting · MCP engineering
MCP server engineering and security audits: connect your systems to AI agents, and check they are secure.
Consulting engagement
MCP is the open standard that lets AI agents use your software's data and actions. You want agents to use the systems you already run, without rebuilding them and without giving an agent more access than its job needs.
- Your existing systems reachable by agents, connected at agreed points, with no rewrite
- Each agent limited to what its job needs; a person approves sensitive actions
- An audit report of what we tested, what we found and what we did not check, with a plan of fixes
Tell us what your agents do and what they touch. We reply by email.
An MCP server exposes a system's data and actions to AI agents as tools through the Model Context Protocol. Aelsha Innovations designs and builds MCP servers around existing systems, and audits them against the MCP specification's security best practices and the OWASP MCP Top 10. The current specification version is 2026-07-28 (verified 2026-10-26).
Source: MCP security best practicesSource: OWASP MCP Top 10 (beta)
Technical detail: standards, methods and what we check ↓Terms used on this page
- AI agent
- software that reads a request, decides what to do and acts in your systems.
- MCP (Model Context Protocol)
- the open standard that lets AI agents use your software's data and actions.
- MCP server
- a small service that offers one of your systems to agents as named actions and data, within limits you set.
- Least privilege
- each agent reaches only what its one job needs.
- OWASP
- a non-profit that publishes widely used lists of software security risks.
MCP engineering
- Agents
- Consent gate
- Scope gate
- MCP server
- Your existing system
An agent reaches your existing system only through an MCP server, past a scope gate and a consent gate, with a person approving sensitive actions.
What the diagram shows
| Step | What it does |
|---|---|
| Your existing system | The database, API or application that holds the data and does the work. |
| MCP server | Wraps that system and offers it to agents as a small set of named tools. |
| Scope gate | Checks the token was issued for this server and allows only the permissions the task needs. |
| Consent gate | A person approves sensitive actions before they run. |
| Agents | Call the tools they are allowed to; every call is logged. |
What we build around your existing systems
We build the layer that lets agents use the software you already run, with permissions and approvals designed in from the start rather than added later.
MCP servers around existing systems
A server that wraps a legacy application, database or internal API as a short list of well-described tools, so agents can use it without rewriting it.
A2A interoperability
Agent2Agent (A2A) is an open standard for agents built by different teams to talk to each other. We design how your agents discover, call and trust one another.
Agent identity and authorisation
Each agent acts as its own identity with short-lived, narrowly scoped access, and sensitive steps ask a person to approve.
The audit: what we check in an MCP server
We review a named MCP server against the security best practices in the specification version in force when the audit starts, and against the OWASP MCP Top 10 (a beta list of the main risks). Each check is run against a real, running server, with evidence recorded.
Authorisation and token handling
- The server accepts only tokens issued for it, and never passes a client token on to another service
- Every request is verified; holding a state handle is not proof of identity
- Scopes start minimal and rise only on request, with no wildcard permissions
- Secrets and tokens never appear in logs, errors or tool output
Consent
- Each client is approved per user before a third-party sign-in begins
- The consent screen names the client and the permissions, and resists framing and forged requests
- Redirect addresses match the registered value exactly
Tool-definition integrity
- Tool names, descriptions and schemas are reviewed for hidden instructions
- Definitions are pinned by hash, so a silent change needs re-approval
- Dependencies are pinned, audited and from verified sources
Input validation
- Every tool argument is checked against a schema; no command or query is built by joining strings
- Outbound requests cannot reach private or internal addresses
- Tool results carry only what the task needs, and instructions inside results are treated as data
Sandboxing
- Local servers run with minimal file, network and system access
- A local server setup shows the exact command and asks for approval
- Links are never opened through a shell
Logging
- Every tool call is recorded with who, which tool, outcome and a correlation ID
- Alerts exist for scope increases, repeated sign-in failures and tool-definition changes
- A kill switch can disable a single tool, and has been tried
Findings are mapped to the matching control in the specification and to the OWASP list, with the evidence to reproduce each one.Source: MCP security best practicesSource: OWASP MCP Top 10 (beta)Source: Invariant Labs on tool poisoning
What you receive
You get a report you can act on, and the tooling to repeat the checks yourself.
- Audit report: summary, scope and pinned specification version, method, findings with evidence, impact and severity, and the limits of the audit
- Tool and permission inventory: each tool, its inputs, side effects, credentials and approval requirement
- Remediation plan: each finding with a fix, an owner, an effort class and a retest criterion
- Completed checklist for every server in scope
- Tool-definition hash manifest, so changes are caught before an agent uses them
The report states what was tested and what was found. It does not claim that a server is secure. Fixing findings is offered as a separate follow-on.
How an audit runs
An audit moves through four phases. How long it takes depends on the number of servers in scope and on how your team works, so we agree the scope and the schedule with you at kick-off. Testing happens only in environments you own and have authorised in writing.
- 01
Authorise
Before any testing: written authorisation and rules of engagement, environment access, and the specification version pinned.
- 02
Map and review
Tool inventory, trust boundaries, and a static review of code, dependencies and the authorisation design.
- 03
Test
Hands-on testing in your authorised environment: arguments, scopes, tokens, definition changes and logs.
- 04
Report
Report, remediation plan, a read-out with your team, and an agreed retest window.
Questions about MCP engineering
What is an MCP server?
An MCP server is a small service that offers a system's data and actions to AI agents as named tools, using the open Model Context Protocol. The agent asks the server to do something; the server decides whether it is allowed.
Is MCP engineering a product?
No. It is a consulting engagement: we design, build or audit MCP servers for your systems, and you own the result.
Do you promise a server is secure after the audit?
No. An audit shows what was tested and what was found at that time. The report says so plainly and includes the limits of what we checked.
Do you test our live systems?
Only environments you own and have authorised in writing, preferably with synthetic data. Testing systems behind the server needs separate written approval.
Which version of the specification do you audit against?
The version in force when the audit starts, pinned in the report. The current version is 2026-07-28.
Tell us which systems you want agents to use
Describe the system and what you want agents to do with it. We reply by email with the questions that decide scope.