Skip to main content
Version: Latest

MCP Servers PBAC Protects

The PBAC Gateway sits in front of any HTTP backend and exposes its operations as MCP tools. Below is the catalog of backends with ready-made scope models and policy templates.

Each entry has:

  • What it is — one line
  • Scopes — the scope names policy can enforce
  • Tools — the MCP tools exposed to clients
  • Example policy — what good looks like for this backend

Don't see yours? Add a new backend in ~30 minutes or contact us.


GitHub

What it is: GitHub REST API — repositories, issues, pull requests, organizations.

Scopes:

ScopeCovers
github:repos:readRead files, commits, branches, search code
github:repos:writePush files, create/update files, create branches
github:issues:readRead and search issues
github:issues:writeCreate issues, add comments, close issues
github:prs:readList and read pull requests
github:prs:writeCreate and update pull requests
github:prs:mergeMerge pull requests (separate — high risk)
github:org:readList org repos, search repositories, get user info

Tools: get_file, list_commits, list_branches, search_code, create_or_update_file, create_branch, get_issue, list_issues, search_issues, create_issue, add_issue_comment, get_pull_request, list_pull_requests, list_pr_files, create_pull_request, merge_pull_request, list_org_repos, get_user.

Example policy: four tiers — developer (everything except merge), ci_agent (read code + manage PRs), read_only (read-only), trusted (all including merge). The merge scope is deliberately separate — it's the only write that cannot be reversed cleanly.

Ready-made scenario: select GitHub from the scenario picker in your instance's Gateway tab.


GitLab

What it is: GitLab API — projects, repositories, branches, files, commits, merge requests.

Scopes:

ScopeCovers
get_projectRead project metadata
list_treeList files and directories
get_fileRead raw file contents
create_branchCreate new branches
commitCommit file changes
create_mrOpen merge requests

Tools: get_project, list_tree, get_file, create_branch, commit, create_mr.

Example policy: engineering role gets everything; analytics gets read-only (get_project, list_tree, get_file); contractor gets nothing.

Ready-made scenario: select GitLab from the scenario picker in your instance's Gateway tab.


Google Workspace

What it is: Unified Google Workspace surface — Drive, Docs, Sheets, Gmail, Calendar, Admin SDK.

Scopes: scoped per Workspace surface, for example:

ScopeCovers
workspace:drive:readRead Drive files
workspace:drive:writeWrite/create Drive files
workspace:gmail:readRead Gmail messages
workspace:gmail:sendSend email
workspace:calendar:readRead calendar events
workspace:calendar:writeCreate / update / delete events
workspace:docs:*, workspace:sheets:*Documents and spreadsheets
workspace:admin:*Admin SDK — high risk

Example policy: isolate workspace:admin:* behind an internal_trusted tier; grant read scopes broadly for analytics agents; require step-up auth for gmail:send and calendar:write.

Ready-made scenario: select Google Workspace from the scenario picker in your instance's Gateway tab.


Google Drive (standalone)

What it is: Drive-only variant for when you just need file read/write.

Scopes:

ScopeCovers
drive:readList and read files
drive:writeCreate and update files

Tools: list_files, read_file, write_file.

Example policy: ship drive:read to every role by default; gate drive:write behind an explicit grant.


Slack

What it is: Slack API — channels and messages.

Scopes:

ScopeCovers
slack:readList channels, read channel messages
slack:writeSend messages (including threaded replies)

Tools: list_channels, read_channel, send_message.

Example policy: agents get slack:read by default; slack:write requires a named trust tier plus a rate-limiting obligation.


Jira

What it is: Jira API — tickets, projects, JQL.

Scopes:

ScopeCovers
jira:readSearch tickets via JQL
jira:writeCreate and update tickets

Tools: search, create_ticket, update_ticket.

Example policy: reads are broadly allowed; writes are scoped per-project via a project argument inspected in Rego.


Jenkins

What it is: Jenkins REST API — jobs, builds, artifacts.

Scopes:

ScopeCovers
get_buildRead latest build status
get_artifactDownload build artifacts
trigger_buildTrigger a new build

Tools: get_build, get_artifact, trigger_build.

Example policy: separate trigger_build from read scopes; require step-up auth before triggering production pipelines.


PostgreSQL

What it is: SQL-over-MCP — scoped database access where the gateway enforces what kind of query is allowed.

Scopes:

ScopeCovers
db:readSELECT queries
db:writeINSERT, UPDATE, DELETE
db:ddlCREATE, ALTER, DROP
db:adminRole and grant management

Tools: db_query, db_exec, db_drop_table, db_list_tables, and so on — categorized per scope.

Example policy: analytics tier gets db:read only; a migrations agent gets db:ddl during a window; db:admin is internal-trusted only.

Ready-made scenario: select PostgreSQL from the scenario picker in your instance's Gateway tab.


Adding a new backend

Any HTTP API becomes a gateway-protected MCP server via YAML:

backends:
- name: my-service
url: "https://my-service.internal"
resource_type: urn:acme:my-service
routes:
- pattern: "/api/v1/items/{id}"
methods: [GET]
scope: myservice:read
mcp:
name: get_item
description: "Fetch an item by ID"
input_schema:
type: object
properties:
id:
type: string
required: [id]
  • pattern — the backend path template
  • scope — the PBAC scope the gateway requires to forward the call
  • mcp.name / description / input_schema — what the MCP client sees

Deploy the gateway with this config, seed the scope in policy data, and you are done. See the Gateway overview for the full model.

If your backend is popular and isn't in the catalog yet, tell us — we'll add it, build a demo scenario, and ship a policy template.


Next steps