Skip to content

MCP Security

6 min read


The MCP server exposes no tool that creates, edits, deletes, executes or imports anything. There is no setting that turns writing on, so it can’t be granted by accident.

So a connected AI can’t change your data, whatever it is asked to do or told to do by something it reads.


A connection reads exactly what the credential behind it reads, resolved fresh on every request against your current memberships.

  • Remove someone from a project, and their connected clients lose it on the next call.
  • A role that cannot open the Defects screen cannot read defects over MCP.
  • Nothing is cached into the credential at the moment you connect, so a grant cannot outlive the access it was made against.

Records contain text people wrote — test case steps, defect descriptions, comments. An AI reading them may encounter instructions embedded in that text.

Because every tool only reads, the worst an injected instruction can achieve through Hawzu is to make the AI query something else and report it back to you. It cannot change your data.

It can, however, influence what the AI tells you. Treat an AI’s summary of your test data the way you would treat a colleague’s — useful, and worth checking before you act on it.


An access token is created for one purpose or the other, chosen at creation and not changeable afterwards.

  • A token created for the REST API is refused on /mcp.
  • A token created for MCP is refused everywhere else.

A token made for a CI job can’t quietly become a way to hand a whole project’s records to an AI client. And an MCP token, which gets pasted into third-party AI clients, can’t be used for anything except reading over MCP.

Changing what a token is for means creating a new one and revoking the old.


An MCP access token reads every project in the workspace it was created in, and nothing anywhere else. There is no role or project to choose: an MCP token can only read, and its permission can’t be given to a person or added to a custom role.

A project added to the workspace later is readable straight away, with nothing done to the token. It does not expire unless you gave it an expiry, so it is the credential to be careful with.

MCP tokens are revoked, not disabled — there is no disabled state. Revoking one takes effect on its next call.

Signing in creates a credential that acts as you in one workspace, expires hourly and refreshes silently. You can revoke it, and so can an administrator of that workspace. It is the safer default where the client supports it.


Any application can call itself anything, so the name on the consent screen doesn’t prove who it is.

You also choose which workspace the connection is for. That choice is required, and it is enforced: the application can read that workspace and no other. To connect the same application to a second workspace, authorise it again from there — that is a separate connection, revocable separately.


Connections appear in two places, and they answer different questions.

Workspace administrators — workspace Settings → Security → Connected apps lists every member’s connections to that workspace: which AI clients can read it, and whose account each is using. Managers and coordinators can disconnect any of them, the same roles that manage access tokens. To see what a connection has actually asked for, see Reviewing MCP activity.

Each member — personal Settings → Security → Connected apps lists what they have connected, across every workspace. It stays available to them whatever their role in those workspaces becomes, because a connection acts as them and is theirs to withdraw.

  1. Open the relevant Connected apps list.

  2. Find the application and choose the disconnect action.

  3. Confirm.

Revocation takes effect on the client’s next call, not at the end of the hour its credential had left. Disconnecting one workspace’s connection leaves the same application connected to any other workspace it was separately authorised for.

To revoke an access token instead, use the Access Tokens page. See Manage access tokens. That cuts off every client using that token.


Each credential can run about 30 queries a minute. That is far more than a person asks through an AI client, and an AI stuck in a loop is stopped within a minute rather than left to run.

When the limit is reached, the AI is told it is looping and should stop, rather than getting an error it might just retry.

If a client reports being rate limited, it is usually looping — asking the same thing repeatedly rather than narrowing one query.


The question is kept. The answer is not.

Every call an AI client makes is recorded — which tool it used and what it asked for. Nothing that comes back is recorded: not the rows, not the records, not their contents. Hawzu keeps no copy of the test data an AI reads through MCP.

For each call we keep a record of:

  • Who asked: the member, or the MCP access token by name.
  • Which application, for a sign-in connection. This is recorded nowhere else: a sign-in connection acts as the person, so every other log names them rather than the agent working on their behalf.
  • What was asked: the tool and the arguments it was called with. A paging token is recorded only as “next page”, because it is part of a previous answer.
  • How it went: served, refused, rate limited or failed, with the reason for a refusal.
  • Counts and timing: how many rows came back, the size of the response and how long it took. Only counts are kept, never the rows themselves.
  • Where it came from: the IP address and the client’s user agent.

Refused calls are recorded too. A revoked token being retried, or a client repeatedly asking for something its role cannot read, is visible rather than silent.

Workspace managers can review every call in Workspace Settings → MCP activity. Filter by member or token, application, project, tool, outcome and date. Open a call to see exactly what was asked, when, and from where. From Connected apps, the activity action on a connection opens this list already filtered to that connection.

MCP activity sits beside the audit logs, not inside them. Audit logs are the permanent record of changes; every MCP call is a read. Hawzu’s own operators can see the same records for support and investigation.