Security and permissions for MCP test management

01The model in one table

Question a reviewer asks	Answer
Whose permissions does the agent have?	The key owner's: access level, global role, project access and its exceptions
Can it reach another workspace?	No. A key works only in the workspace it was created in
What scope does the key carry?	`mcp`; it works on the MCP endpoint only
Who can create one?	Any signed-in user, for themselves; no admin step and no plan gate
How long does it live?	30 days, 90 days (the default), 1 year, or never (marked Not recommended)
How is it stored and shown?	Shown once at creation; the list shows only its prefix, `to_live_…`
How do I stop it?	Revoke it; the next request is refused with HTTP 401
How do I know it is in use?	The Last used column; Never for a key that has not authenticated
Who is a write attributed to?	The key owner's account

02Personal keys act as their owner

Every MCP request carries a personal key in an Authorization: Bearer header. TestOrchestrator resolves the key to the person who created it and runs the tool as that person: their access level, global role and project access. Write tools need the same permissions they need in the app, so a key whose owner cannot edit a project cannot create cases in it. A key never widens what its owner can do.

Errors do not leak existence: a project or case the key cannot reach is answered "not found or access denied", whether or not it exists. A missing, invalid, revoked or expired key gets HTTP 401, and the key value is never echoed back or written to logs.

03Scope and surface

TestOrchestrator has two kinds of key and each works on one surface. A personal key has the mcp scope and works on /mcp. A workspace service key is for CI: scopes ingest:results and optionally read, bound to one project (or explicitly to all), and it works on the public API only; on /mcp it is refused like an unknown key. See API keys.

04Expiry, last use and revocation

Expiry is a choice with a safe default. The create dialog offers 30 days, 90 days, 1 year or never, and starts on 90 days. A banner warns when an active key is within two weeks of expiry.
Last used. Each row shows when the key last authenticated a request. A key that never has reads Never, with the hint that the client using it may be misconfigured.
Revocation is immediate and final. We revoked a key that a client had used the same day: the confirm named the evidence ("This key authenticated a request today, so something is using it right now"), asked us to type REVOKE, and the next MCP request with that key was refused with HTTP 401. There is no reactivate action; rotation is create, update the client, then revoke.

05What an agent cannot do

Act outside its owner's permissions or workspace.
Delete test cases, runs, folders or projects: no MCP tool does. The one delete tool removes a comment.
Create projects, invite or manage users, change roles, create keys or change workspace settings: there are no tools for these.
Use a service key on MCP, or a personal key on the CI upload API.
Read data through semantic search: search_test_cases matches on title and case number.

Attachments removed in the app are removed immediately and cannot be restored, and a deleted test case cannot be restored either, so keep destructive work with people.

06Attribution and audit

An agent's writes are stored as the key owner's: in our test, the case Codex created carried the same createdBy user as the folder the owner made by hand. That keeps responsibility with a person, but it also means:

There is no separate audit log of agent actions in TestOrchestrator today, and the case view does not mark a case as agent-created.
Use one key per client and per person, labelled so you can tell them apart ("Claude Code, Sam"), and revoke a key when its client is retired.
Use a workflow state for agent output. Ask agents to create cases in Draft and move them on after review; see how to review test cases created by AI agents.

07What to tell your security reviewer

The agent authenticates with a personal key over HTTPS to api.testorchestrator.com/mcp; the key is shown once and only its prefix is kept for display.
The key acts as one named user, inside one workspace, with that user's existing permissions. No new privileges are created.
Keys expire (90 days by default), show their last use, and are revoked on the next request.
The tool set is fixed and listed in the tool reference; it has no tools for deleting cases, managing users or changing settings.
Agent writes are attributed to the key owner; there is no separate agent audit log, so review agent output through a Draft state.
Where the data lives is on the sub-processors page.

09Frequently asked questions

Can an AI agent do more than I can?

No. A personal key carries its owner's access level, role and project access. If you cannot open or edit a project, neither can the agent; a project it cannot reach is answered "not found or access denied", the same as one that does not exist.

How do I see what an agent did?

Its writes are recorded under the key owner's account, like edits the owner makes in the app, and the key list shows when each key last authenticated. There is no separate audit log of agent actions, and a case does not say whether a person or an agent created it, so label keys per client and use one key per agent.

What happens when I revoke a key?

The next request with it is refused with HTTP 401. A revoked key cannot be reactivated; to rotate, create a new key, update the client, then revoke the old one. If the key was used in the last week, the confirm asks you to type REVOKE.

Can an agent delete test cases over MCP?

No. None of the 39 MCP tools deletes a test case, a run, a folder or a project; the only delete tool removes a comment. An agent also cannot create projects, manage users or change workspace settings.

Can a CI service key be used for MCP?

No. Workspace service keys are for uploading results to the public API, are bound to a project, and are refused on the MCP endpoint like an unknown key.