MCP access control for AI agents.
Give each caller a scoped key and configure permissions for tools, operations, parameter values and response fields. Connect Claude or Cursor to Jira without granting unrestricted access.
Example: connect Claude to Jira with limited permissions
Illustrative policy for a support assistant: read and search issues in project MOB, without deleting issues or receiving email addresses. Use the same checks when connecting Cursor or another MCP client.
Choose the resource and operations
Configure the Jira integration and allow only the required read and search operations for project MOB. Keep delete operations outside the allowed set.
Set the response policy
Configure the relevant email fields for redaction. Resource restrictions and response policies solve different problems: which issues are accessible and which fields are returned.
Connect the client
Issue a scoped key for the caller and configure the supplied MCP endpoint in the client. Keep the key secret; the Jira credential stays in the gateway deployment.
Verify allowed and denied calls
Read an issue in MOB, then attempt a request outside MOB and a delete operation. Confirm the denials, inspect returned fields and review the audit trail before expanding access.
Why on/off isn’t access control
A connector you can only switch on or off can’t express what an agent should actually be allowed to do.
- 01
All-or-nothing tokens over-grant
A single personal access token usually carries everything its owner can do: every repo, project and channel, far more than one agent needs.
- 02
Misconfiguration can escalate privilege
Without an enforced organisation ceiling, a project owner could hand out more access than the org ever intended.
- 03
Shared credentials erase attribution
When agents share a key you can’t tell which one acted, or revoke one without breaking the rest.
- 04
A leaked long-lived key is a standing liability
Machine credentials that never expire or rotate stay valid for as long as it takes anyone to notice they leaked.
MCP access control at four levels.
Configure which tools an agent can use, which operations it may run, which parameter values are allowed and which response fields it receives. An organisation-wide ceiling limits the permissions each project can grant.
Example: let an agent read Jira issues in project MOB, deny delete operations and redact email addresses from the response.
How Vordix solves it
- 01
Four levels of control
Govern the tool, the operation within it, the parameter values that are allowed, and how response fields are handled, not just on or off.
- 02
Admin ceiling, project subset
Admins set what is possible for the whole org; each project draws a subset within that ceiling and can never exceed it.
- 03
Hard per-parameter allowlists
A caller can’t widen a query beyond the project’s selection. Databricks columns, for instance, are an allowlist with no wildcard, so a new PII column stays closed by default.
- 04
One scoped key per identity
Each user and agent gets its own key, resolved to its memberships on every call, stored only as a hash and shown exactly once.
- 05
A personal endpoint per key
Every key gets an MCP endpoint that lists exactly the tools it is permitted. A tool only appears if the caller could be allowed it.
- 06
Instant revoke, rotate, kill switch
Disable or rotate any human or agent key in a click, with an org-wide kill switch that blocks all traffic and revokes every key at once.
- 07
Per-parent parameter scoping
Allow different values per project (issue type Bug for one project, Task for another) within the same operation.
- 08
SSO and MFA
Bring your own identity provider, with MFA enforced across the org.
See it on your own stack.
A short walkthrough on your tools, your rules, your audit log. Nothing leaves your network.