AI access checklist
What should your business check before AI can use company systems?
Use these questions with any MCP provider or internal implementation. A useful demo is not enough. The business should be able to explain who has access, where that access stops, and what happens when something changes.
What should an MCP access layer prove?
A business MCP setup should prove who is asking, which workspace they belong to, which apps and actions they may use, and when confirmation is required. It should also keep provider credentials private, bound the amount of data retrieved, support revocation, record useful activity metadata, and make denials and failures understandable.
This checklist is an evaluation framework, not a certification. Ask for product evidence and test the controls with your own roles and systems before expanding access.
Twelve questions to ask
- Who is asking?
The connection should identify a real person or intentionally managed service account, not rely on a shared anonymous credential.
- Which company or workspace are they acting in?
Every request should resolve to one explicit business boundary before any tool runs.
- Which apps may they reach?
Connecting an app for the company should not automatically make it available to every person.
- Which actions may they use inside each app?
Access should be narrower than an entire provider API and limited to the tools required for the job.
- Are reads and changes treated differently?
Creating, changing, sending, approving, or deleting usually deserves a narrower grant than reading.
- Where are provider credentials kept?
The AI conversation and client should not receive the password, token, or private key used for the business system.
- What does a person confirm?
For a higher-impact action, the person should see the actual target and arguments, not approve a vague category.
- How is the amount of data bounded?
Reads should use appropriate limits, time ranges, filters, and continuation instead of silently pulling an entire system.
- Can each kind of access be revoked?
The company should be able to remove a person, session, key, app connection, or tool grant without dismantling everything else.
- What activity is recorded?
Useful records identify the actor, workspace, app, tool, outcome, action type, and time without unnecessarily retaining secrets or full returned data.
- How are failures and denied requests shown?
Administrators need to distinguish an access denial, provider problem, expired connection, and invalid request.
- Which risks still belong to the company?
The business still owns its AI-use policy, provider scopes, user access, workflow design, review process, and response to a compromised identity.
What evidence should a buyer request?
| Claim | Useful evidence |
|---|---|
| People have different access | Two test users receive different tool catalogs and the restricted user is denied again at execution. |
| Credentials stay private | The client result, routine logs, and activity screen do not reveal the provider secret. |
| A change needs confirmation | Changing the target or arguments invalidates the previous approval. |
| Access can be revoked | A cached or previously discovered tool fails after its grant, session, or connection is removed. |
| Activity is reviewable | An administrator can identify the person, workspace, app, tool, outcome, and time without exposing the returned business data. |
How Stackyapper maps to this checklist
Stackyapper uses workspace, app, tool, group, user, risk, and confirmation controls around its remote MCP endpoint. Its security page documents the implemented sequence, operational audit fields, retention, and shared-responsibility boundary. The technical MSP checklist adds controls for multi-customer environments.
Frequently asked questions
Does MCP eliminate prompt-injection risk?
No. Access controls can reduce exposure and limit actions, but they do not eliminate misleading instructions, compromised identities, unsafe source content, or mistakes by the AI or user.
Is authentication enough?
No. Authentication establishes who is making the request. Authorization decides which workspace, app, tool, and action that identity may use.
Should read and write actions use the same policy?
Usually not. Changes can affect customers, money, systems, or records, so they often deserve narrower grants and an additional confirmation step.
Is there a checklist for MSPs and multiple customers?
Yes. The Stackyapper MSP checklist adds technical checks for strict customer-workspace isolation, credential ownership, bounded reads, outbound requests, and incident response across customer environments.