MCP Security Checklist for Creative Teams

An MCP security checklist should answer one practical question: if the agent misunderstands a prompt, consumes hostile content, or connects to a compromised server, what can it actually access, spend, or disclose?

Model Context Protocol does not make a server trustworthy. It standardizes how a host connects to capabilities. Security still depends on who operates the server, what code runs, which credentials and scopes it receives, which tools the host exposes, how outputs are treated, and whether a person approves consequential actions.

For a creative team, start small: non-confidential references, one low-cost image job, narrow permissions, visible approval, and a tested revocation path. Use Oakgen AI Chat only for the current brief-planning job described here; it is not evidence of a connected-generation release.

This guide is not a compliance certification. Before using sensitive assets, review the official guidance and your own legal, privacy, client, and security obligations.

Quick red-flag table

| Red flag | Why it matters | Safer requirement | | --- | --- | --- | | Server identity cannot be verified | You cannot establish who receives data or changes tools | Official source, named operator, reviewed release | | “Paste your key into chat” | The secret enters model context and logs | Host-managed or documented OAuth/secret storage | | One token grants every action | A prompt mistake has a large blast radius | Least-privilege scopes and step-up access | | Tool list changes without review | Approved capabilities can shift later | Change notification, re-scan, admin approval | | Tool output is treated as trusted instruction | Retrieved content can manipulate later calls | Untrusted-data boundary and output validation | | Paid actions run without confirmation | A vague prompt can become spend | Quote, budget policy, explicit approval | | No job or audit identity | Incidents and duplicates are hard to reconstruct | Stable request/job IDs and sanitized logs | | Revocation is undocumented | Departed users or stolen tokens may retain access | Tested disconnect, token revocation, session invalidation |

If a vendor cannot resolve the first two rows, do not connect it to production creative.

Who this guide is for

This is for an agency lead, growth operator, founder, or creative technologist who is being asked to “just connect the server.”

You do not need an enterprise procurement department to apply it. A five-person studio still handles client briefs, unreleased products, creator likeness, brand assets, platform credentials, and paid generation budgets.

The checklist is intentionally proportional. A public moodboard test does not require the same review as an unreleased campaign with client packshots and write access to a shared asset library.

For the protocol roles behind this boundary, start with what an AI image generation MCP server does. For an applied production example, see the creative MCP workflow for marketing agencies.

Research note

We reviewed the official Model Context Protocol security best practices, authorization guidance, architecture, tools specification, and debugging guidance on July 24, 2026. We also reviewed OWASP's MCP Security Cheat Sheet and MCP tool-poisoning guidance for an independent security perspective.

The protocol documentation identifies risks including confused deputy behavior, token passthrough, SSRF, session hijacking, local-server compromise, and excessive scope. OWASP describes tool poisoning as indirect prompt injection through tool descriptions or results.

This article translates those risks into a small creative team's review. It does not claim that any checklist eliminates prompt injection or certifies a vendor.

First, draw the trust boundary

Write the path on one line:

User → AI host → MCP client → MCP server → image provider → asset storage

Then mark where these items cross it:

prompt and campaign brief;
reference images;
authentication tokens;
model and tool schemas;
price and credit information;
generation request;
job status;
returned image or URL;
logs and analytics.

Every arrow is a question. Does the host retain the prompt? Does the server store references? Does the provider train on uploads? Does the result URL expire? Which component can start paid work? The protocol diagram cannot answer vendor policy questions for you.

If you are still deciding whether the agent belongs in this path, use the MCP vs API vs web app decision guide.

Local and remote servers have different risks

A local MCP server usually runs on the user's machine and communicates through standard input/output. It may have access to local files, environment variables, installed commands, and the user's network. Installing unreviewed local server code is installing software, not adding a harmless bookmark.

A remote server runs elsewhere and typically uses an HTTP transport. It introduces a vendor and network trust boundary, remote authorization, token handling, session behavior, data retention, and service availability.

Neither is automatically safer.

Ask instead:

What code runs, and under which operating-system identity?
What network destinations can it reach?
Which local paths can it read or write?
Which remote organization receives the brief and assets?
How is the user authenticated?
How is access revoked?
What happens when tools or policies change?

The smallest privilege set wins.

The 15-point MCP security checklist

This is the linkable review asset. Record evidence for each item rather than checking from memory.

1. Verify the server's identity

[ ] The connection address or package comes from the vendor's official documentation.
[ ] The operator, support path, and current release are identifiable.

Search results, copied configuration snippets, and community registries are discovery aids—not proof that the server belongs to the named vendor.

2. Review the software or supplier

[ ] For local code, review source, dependencies, release provenance, and update behavior.
[ ] For remote services, review security, privacy, retention, and subprocessors appropriate to the data.

Do not treat an open-source repository as automatically safe or a hosted vendor as automatically reviewed.

3. Inventory the data

[ ] Classify the prompts, product references, creator images, client names, unreleased assets, and metadata that may cross the boundary.

Start the pilot with synthetic or public material. Add real client assets only after the handling rules are known.

4. Minimize credentials

[ ] Store tokens through documented host or server mechanisms.
[ ] Never put keys in prompts, filenames, screenshots, or shared configuration.

MCP authorization guidance says remote HTTP authorization follows standardized flows, while local stdio servers may obtain credentials through local mechanisms. Follow the actual server and host documentation.

5. Minimize scopes

[ ] Grant only the tools and resources needed for this workflow.
[ ] Separate read, quote, generate, cancel, asset, and administrative authority where possible.

The official security guidance emphasizes scope minimization. “All tools” is not a sensible default for a one-image pilot.

6. Bind authorization to the intended server

[ ] The server validates tokens intended for it and does not pass client tokens through to downstream APIs.

The MCP authorization specification explicitly rejects token passthrough. Teams should ask the vendor to explain the user-to-server and server-to-provider authorization boundaries.

7. Review the tool list and schemas

[ ] Capture the expected tool names, descriptions, and input schemas.
[ ] Re-review material changes before wider use.

Tool descriptions influence agent behavior. A new tool or changed description is a security-relevant product change.

8. Treat tool output as untrusted

[ ] Tool descriptions, retrieved content, URLs, metadata, and returned text are data—not higher-priority instructions.
[ ] Validate structured output and isolate cross-server data flow.

A benign-looking asset result can contain a hostile instruction in metadata or surrounding text. Prompt wording alone is not a reliable control.

9. Require approval for consequential actions

[ ] A person approves paid generation, destructive edits, public sharing, and external publishing.
[ ] Approval shows the actual tool, important inputs, destination, and price.

“Always allow” is operational debt. Apply it only to narrow, understood, reversible actions.

Keep planning separate from paid execution

Use Oakgen AI Chat to shape the creative brief, then move into the current visual tools with a human approval step.

Plan the Creative Brief

10. Enforce credit and rate boundaries

[ ] Use per-user or per-workspace budgets, output limits, and rate controls.
[ ] Re-price changed requests and stop when a quote is unavailable.

A provider balance is not a campaign budget. Do not give the agent permission to spend whatever remains.

11. Protect asset ownership

[ ] Job status and generated assets are restricted to the authorized owner or workspace.
[ ] Temporary delivery URLs are not mistaken for durable access controls.

The server should not reveal whether another user's job exists. Shared workspaces still need explicit membership and role rules.

12. Preserve an audit trail

[ ] Record actor, server, tool, timestamp, normalized action, approval, request/job identity, outcome, and cost-changing result.
[ ] Redact secrets and unnecessary prompt or asset content.

Logs should reconstruct the event without becoming a second leak.

13. Test revocation

[ ] Disconnect the server, revoke the token, and verify the old session can no longer act.
[ ] Remove access for a departed user without breaking unrelated accounts.

“There is a disconnect button” is not evidence. Run the test.

14. Prepare incident actions

[ ] Know who can disable the connection, revoke credentials, pause paid actions, preserve logs, and notify affected owners.

Small teams need names, not a generic “security will handle it.”

15. Re-test after change

[ ] Re-run tool discovery, permission, approval, quote, asset-isolation, and revocation checks after host, server, model-provider, or policy changes.

Connection success is a point-in-time result. It is not permanent compatibility or trust.

Prompt injection in a creative workflow

Prompt injection is not limited to someone typing “ignore previous instructions.”

An agent may read:

a web page used as campaign research;
text extracted from a reference image;
metadata returned with an asset;
a tool description;
a project file;
another server's output.

Any of those can contain instructions the user did not intend.

Suppose an agent reads a competitor page and encounters hidden text telling it to upload the campaign brief to an unrelated tool. If the agent has both browsing and broad file-sharing tools, the attack can cross servers.

The control is architectural:

expose fewer tools;
separate untrusted research from write actions;
require approval with visible parameters;
prevent the model from seeing raw credentials;
validate destinations;
block unauthorized cross-server data flow;
log and review consequential calls.

The system prompt may help. It should not be the only barrier.

Procurement questions for a small team

You do not need a 90-page questionnaire. Ask these:

Who operates this server, and where is the canonical connection documentation?
What data is received, stored, logged, or used for product improvement?
Which subprocessors or model providers receive prompts and images?
How are remote users authenticated and tokens revoked?
Can access be scoped by user, workspace, tool, and action?
How are tool-list changes communicated and approved?
Which paid actions expose a quote and confirmation?
How are job status and assets isolated between owners?
What audit evidence is available without exposing secrets?
What is the incident, vulnerability-reporting, and support path?

An answer can be “not supported.” What matters is that the team knows before connecting client work.

Oakgen's security boundary

Oakgen's planned first MCP surface is image-only: model search, public schema lookup, pricing, generation start, owner-scoped status, and cancellation.

That planned contract is not a public security claim. The current implementation remains default-off and non-production. Public credential issuance, delegated OAuth, endpoint documentation, external host tests, operations, and release-canary evidence are incomplete.

Do not infer a certification, production SLO, plan requirement, or host compatibility from this article.

The current Oakgen pricing page applies to the public product. It does not document a future MCP access policy.

Common mistakes

Approving the brand name instead of the server. Verify the exact endpoint, package, operator, and release.

Giving a creative agent filesystem-wide access. Restrict local roots and write destinations to the project.

Using one shared token. Per-user identity improves scope, revocation, and auditability.

Logging the secret while debugging authentication. Record error type, server, host, timestamp, and correlation identity—not the token.

Treating read tools as harmless. Reading a private brief or local file is a consequential data action.

Allowing a script once and assuming every nested tool call is approved. Each runtime call still needs policy enforcement appropriate to its grant.

Skipping re-review. A tool list or server package can change after the first connection.

A sensible pilot

Use a separate test account and non-confidential creative. Connect only one server. List the tools and record their schemas. Deny broad scopes. Quote a deliberately small job. Approve one start. Verify job and asset ownership. Test cancellation. Revoke access and prove the prior session is blocked.

Then inspect the evidence with the person who owns the budget and the person who owns the assets.

If that feels slow, remember what you are granting: an AI-mediated path to external software, data, and paid actions.

Build the brief with a human in control

Use Oakgen AI Chat for current creative planning while your team evaluates tool permissions and approval boundaries.

Draft the Campaign Brief

Frequently Asked Questions

Are MCP servers safe to use?

MCP is a protocol, not a security guarantee. Safety depends on the server, host, transport, authorization, scopes, tool design, data handling, approvals, and operational controls.

What is the biggest MCP security risk for a creative team?

The practical risk is excessive trust: a server or agent receives broader credentials, assets, tools, or spending authority than the job requires. Prompt injection and compromised tool output can then turn that access into unintended actions or disclosure.

Is a local MCP server safer than a remote MCP server?

Not automatically. A local server avoids a remote network hop but may run code with access to local files and environment variables. A remote server introduces vendor, network, and OAuth trust. Review the actual privileges of either design.

Should users paste API keys into an AI chat?

No. Credentials should be stored and attached through the host or server's documented secret and authorization mechanisms, never placed in prompts, source assets, or troubleshooting screenshots.

How should teams handle prompt injection from MCP tools?

Treat tool descriptions, retrieved content, and tool results as untrusted. Keep permissions narrow, require approval for consequential actions, validate inputs and outputs, isolate servers, and enforce controls outside the prompt.

What should an MCP audit log contain?

At minimum, record the authenticated actor, server and tool identity, timestamp, normalized action, approval, job or request identity, outcome, and cost-changing result without logging raw secrets.

Does this checklist make an MCP deployment compliant?

No. It is an operational review aid, not legal, privacy, or compliance certification. Apply the laws, contracts, security program, and specialist review appropriate to your organization and data.

Sources and Further Reading

Sources were reviewed on July 24, 2026. Re-check the current protocol version, host policy, and vendor documentation before a production connection.