MCP governance and access control for agents

MCP governance sets the rules for what an AI agent may read, change and disclose through external tools. AIPx implements access control per tool, connected account and agent, with Allow, Confirm and Hide modes plus a shared audit. Those controls make the permitted boundary explicit; they do not replace upstream account permissions or review of the agent’s task.

What MCP governance means for one developer or a small team

For a developer, governance starts with a practical question: which operations should this particular agent be able to reach? A coding assistant may need the work tracker and error reports. A scheduling assistant may need calendar events and meeting notes. Neither needs every connected service simply because it exists in the account.

Define the job, the accounts and the acceptable effects. Reading acceptance criteria, creating an issue and deleting shared data are different decisions. Writing “ask before changing anything” in a prompt can guide behavior, but enforcing the permitted tool set gives that instruction a concrete boundary.

A small team also needs to understand whose account executes the call. A gateway connection is not automatically a delegated organization role, and an audit is not automatically a compliance system. AIPx’s documented controls focus on account, tool and agent permissions; this page does not imply a team plan, enterprise role hierarchy or retention guarantee.

The MCP gateway guide explains the wider connection model. Here the focus is the rules you can actually review before letting an agent use those connections.

MCP access control per tool, per account and per agent

AIPx evaluates the operation in the context of a connected account and an agent. The same tool can be available for one account and hidden for another. Two agents can also receive different access to the same connected account.

Mode	Effect	Useful starting case
Allow	The permitted call can execute	A relevant, reviewed read operation
Confirm	Metadata requests client-side approval; handling depends on the client	Creating or changing shared data
Hide	The agent has no access to that operation	Irrelevant, destructive or private-account tools

This example is a recommended policy, not a claim about tool identifiers in every integration:

Operation	Work account, coding agent	Personal account, coding agent	Reason
Search project issues	Allow	Hide	The task needs only work context
Read issue details	Allow	Hide	Acceptance criteria are relevant
Create an issue	Confirm	Hide	Review the shared change first
Update a document	Confirm	Hide	Check destination and content
Delete shared data	Hide	Hide	The bug-fix workflow does not require deletion

The product’s ordinary default is Allow for read-only tools and Confirm for other tools, with integration-specific exceptions such as AgentMail’s default Hide. Review the actual discovered operations rather than assuming every service uses identical defaults or supports the same tool set.

Read-only access still needs a confidentiality decision

A read can reveal a customer address, private conversation, internal error payload or health record. It may be harmless to the source system and still unsuitable for a coding conversation. Ask what information can leave the service, not only what data can change.

Hiding writes is useful, but it does not make broad reading appropriate. Restrict the connected account, the agent’s tools and the upstream account scope together. For database access, use provider-level project and read-only restrictions where available; the gateway rule adds another boundary rather than replacing them.

Confirm before writes

Confirm marks the tool with approval metadata for the client. It is an execution hint, not a universal gateway block: the actual review step depends on whether and how the client honors it. Use Hide when an operation must be unavailable. In a client that requests approval, the confirmation must match the requested operation, account and arguments before you approve it. A valid instruction to update one issue is not a reason to approve a call that targets another issue or another account.

Review the fields that determine the effect. For an outgoing message, inspect the recipient and body. For a shared document edit, inspect its destination and content. For a financial operation, inspect the account, customer and amount when those fields are part of the tool. If the details are unclear, do not infer safety from a familiar tool name.

The client controls its approval prompt. Test a harmless Confirm-marked operation in your actual client before relying on a review workflow. If it calls the tool directly without a prompt, Confirm alone does not stop execution. Local command approvals are a separate client boundary.

Confirm is not an enforced transaction preview or rollback promise. Once an approved operation executes, its result and reversibility depend on the upstream service. A model can propose a poor action with valid arguments, so the human review still needs the task context.

Move from Confirm to Allow deliberately

Use Confirm while learning a workflow’s actual calls in a client that honors the approval hint. If a frequently repeated operation is narrow, reversible and has predictable arguments, you may decide that automatic execution fits. Make that decision for a specific tool and account rather than turning an entire integration into an unrestricted connection.

Revisit the rule when the tool description or available operations change. A newly discovered tool should receive a fresh review even if the account has been connected for months. A trusted service name is not an adequate permission specification.

MCP audit logging and monitoring

AIPx’s shared audit records which agent called which tool on which account, with parameters, result and time. It provides one place to inspect calls from different clients using the account connections.

Audit field	Question it helps answer
Agent	Which configured workflow made the call?
Account	Was the work or personal connection used?
Tool	Which operation executed?
Parameters	What destination or input was supplied?
Result	What response did the operation return?
Time	When did the call occur?

Start by checking the first task after onboarding an agent. A returned answer can look plausible even if it came from the wrong account. The audit helps compare the requested source with the source actually called and inspect whether a proposed write ran.

Audit inputs and results may themselves contain sensitive information. Logging a private document does not remove its confidentiality requirements. This page does not promise a retention period, SIEM integration, downloadable export or tamper-proof storage; use only the capabilities the product actually exposes.

Monitoring is most useful when it changes a decision. If the log shows an agent repeatedly calling irrelevant tools, hide those tools or narrow the task. If a provider repeatedly denies access, repair the upstream connection rather than leaving an agent to retry with broader permissions.

Claude Code MCP logs

Claude Code’s /mcp interface and server inspection commands help diagnose connection state, configuration and authentication. They are useful for determining whether a server is available and which tools the client sees. Follow the Claude Code setup guide for the current commands.

A client trace answers questions about that client’s session. The AIPx audit answers questions about calls through the gateway, including another client using the connected accounts. Neither view alone explains every failure: an invalid local configuration happens before a gateway call, while an upstream provider error can occur after the client has successfully connected.

Keep those stages separate when debugging. Check configuration, then client OAuth, then discovered tools and gateway policy, then provider account access. Changing every rule to Allow does not fix an invalid URL and makes the permission boundary harder to assess.

Separate rules for work and personal accounts

The agent OpenAPI interface is another way to consume configured tools, so review its credential boundary too. For publicly reachable endpoints and private local tools, the remote MCP server guide explains the placement decision.

Connect work and personal accounts separately and give them clear labels. Then assign them to agents according to the task. A work development agent should not acquire personal calendar or health context because those accounts were convenient to connect.

A personal planning agent can have its own permission set over notes, calendar and tasks. A billing agent can have a different set over payment systems. The useful separation is in the actual agent rules, not just in the names shown in a client menu.

1. List the services needed for the task.
2. Select the exact connected accounts.
3. Allow the necessary reads after reviewing confidentiality.
4. Put proposed changes on Confirm.
5. Hide unrelated and unnecessary destructive operations.
6. Run one verifiable task and inspect the audit.
7. Revise the rules when the workflow or tools change.

The integration catalog helps identify supported services. The OAuth guide distinguishes client login from upstream account authorization, so you can understand why a tool can be permitted yet still fail at the provider.

Limits of permission rules

Tool rules reduce the reachable action set. They do not prove that every external result is trustworthy, prevent every prompt injection, or guarantee that an approved call is harmless. Treat retrieved content as data and keep the task’s authority separate from instructions embedded in documents or messages. See MCP security and AI agent security for that wider threat model.

AIPx adds another hosted operator. Private network requirements or enterprise policy controls may call for another deployment model. Free includes three accounts and one agent; Pro supports unlimited accounts and agents for $3 per month, with Pro integrations. The pricing page describes that plan boundary. Start with a small permission matrix you can explain. Connect free.