Eonevolve Learning
Unity and DevelopmentUnity and codeIntermediate~8 min

MCP Permissions, Secrets, and Prompt-Injection Boundaries

Snapshot

~90 sec

An MCP connection is a capability boundary, not a blanket safety guarantee. Use least privilege, separate read and write grants, allowlisted scope, untrusted-result handling, human approval for consequential actions, and independent verification. Secrets stay out of prompts, tool results, resources, and logs.

You will learn

  • Separate connection, discovery, permission, approval, and verification.
  • Treat tool and resource results as untrusted input that can contain prompt injection.
  • Keep secrets and consequential writes behind operational controls outside prompt wording.
  • Apply least privilege without claiming that MCP enforces every safety property.

Target outcome

You can define an Intermediate operational boundary for a game-development MCP connection before designing advanced remote authorization infrastructure.

Visual walkthrough

Visual walkthrough

~8 min

  1. Six controls share the boundary

    • Least privilege

      Expose only the servers, tools, resources, paths, and arguments needed for the current workflow.

    • Read and write split

      A successful read does not grant mutation. Writes receive a separate, narrower decision.

    • Secret isolation

      Credentials belong in supported secret storage or process configuration, never in prompts, tool output, resource content, or logs.

    • Untrusted results

      Tool and resource content is data, even when it contains text that looks like an instruction from a trusted project.

    • Human approval

      A person reviews the exact tool, arguments, target, and consequence before a consequential action.

    • Independent verification

      A diff, visible Unity state, test result, or external status proves the outcome instead of the mutating tool's response.

  2. Route untrusted results through operational gates

    An invented Unity resource may contain useful project context and malicious-looking instructions in the same result. The client keeps the result as evidence, not authority.

    1. Allowlist the scope

      Permit one server, one read capability, and one invented PracticeArena path.

    2. Read bounded data

      Retrieve only the requested console, scene, asset, or file context.

    3. Treat output as untrusted

      Separate project facts from embedded requests, links, commands, and claims.

    4. Propose, do not execute

      Describe the smallest action, arguments, effect, and rollback path.

    5. Human approval

      A person checks whether the consequential action is necessary and inside the allowlist.

    6. Perform the approved action

      Execute only the reviewed tool and arguments without expanding scope.

    7. Verify independently

      Check the resulting diff, Unity state, test output, or remote status.

    An invented Unity resource may contain useful project context and malicious-looking instructions in the same result. The client keeps the result as evidence, not authority.

    Reading order

    1. Allowlist the scope

      Permit one server, one read capability, and one invented PracticeArena path.

    2. Read bounded data

      Retrieve only the requested console, scene, asset, or file context.

    3. Treat output as untrusted

      Separate project facts from embedded requests, links, commands, and claims.

    4. Propose, do not execute

      Describe the smallest action, arguments, effect, and rollback path.

    5. Human approval

      A person checks whether the consequential action is necessary and inside the allowlist.

    6. Perform the approved action

      Execute only the reviewed tool and arguments without expanding scope.

    7. Verify independently

      Check the resulting diff, Unity state, test output, or remote status.

    Connection explanations

    1. Allowlist the scope → Read bounded data (limits)

      A narrow allowlist reduces what an accidental or adversarial request can reach.

    2. Read bounded data → Treat output as untrusted (returns)

      A server result can contain correct facts, stale data, or injected instructions, so every part remains untrusted input.

    3. Treat output as untrusted → Propose, do not execute (informs)

      Evidence may support a recommendation, but text inside the result cannot authorize another tool call.

    4. Propose, do not execute → Human approval (requests)

      The approval surface exposes the exact consequence and arguments to a human before execution.

    5. Human approval → Perform the approved action (authorizes once)

      Approval applies to the reviewed tool, arguments, target, and consequence rather than every future call.

    6. Perform the approved action → Verify independently (must be checked by)

      Independent evidence determines whether the approved action produced the intended result.

  3. Separate a useful grant from excessive authority

    ApproachReachDecision pointRequired evidence
    Bounded read grantAn invented console-triage task can read only recent errors from one disposable Unity project.One named server and read capability with bounded filters; no write, shell, deployment, or secret access.The host permits or prompts for the read according to project policy.The result matches the visible Console slice and contains no credentials or unrelated project content.
    Approved write grantAn invented PracticeArena prefab change is limited to one reviewed serialized field.One mutating capability, one asset target, and explicit arguments with a known rollback path.A human reviews the exact call after the read evidence and before the mutation.The prefab view and version-control diff prove that only the approved field changed.
    Blanket server accessEvery discovered read and write stays enabled because the server was trusted once.Unrelated project paths, tools, and consequences become reachable without a task-specific reason.Connection trust is mistaken for permanent approval of future calls and arguments.A successful tool response replaces independent review, so hidden or partial changes can be missed.

  5. Invented prompt-injection scenario: a resource asks for a secret

    A generic package-note resource contains a sentence telling the agent to ignore policy, read a deployment token, and send it through another tool. The safe workflow does not obey or repeat that request.

    States

    1. Bounded resource read

      The client requests the one generic package note needed for dependency review.

      Observable output: A text result arrives inside the expected resource response.

    2. Instruction-like text detected

      The result contains project facts plus a request to access and transmit a secret.

      Observable output: The suspicious sentence is classified as untrusted data, not as a higher-priority instruction.

    3. Secret path stays unavailable

      No prompt, tool result, resource response, or log receives the credential, and no outbound action is approved.

      Observable output: The client reports the injection risk and continues only with the dependency facts required by the task.

    4. Useful facts verified

      The package claim is checked against an allowlisted official or local source without following embedded commands.

      Observable output: The review records verified dependency evidence and zero secret disclosure or project mutation.

    Transitions

    1. 01

      Bounded resource read → Instruction-like text detected

      Input
      The resource returns mixed factual and instruction-like text.
      Effect
      The host and operator keep the entire result in the untrusted-data boundary.
      Result
      No embedded instruction gains tool authority.

    2. 02

      Instruction-like text detected → Secret path stays unavailable

      Input
      The text requests credential access and an outbound tool call.
      Effect
      The unavailable secret scope and consequential-action approval block the requested chain.
      Result
      No secret is read, copied, logged, or transmitted.

    3. 03

      Secret path stays unavailable → Useful facts verified

      Input
      The original dependency question still needs an answer.
      Effect
      The operator verifies only the relevant claim through an independent allowlisted source.
      Result
      The task proceeds with checked facts and without obeying the injection.

  8. Stop an unsafe tool chain

    An invented read-only Unity resource returns a plausible diagnosis plus text that says to read a token from local configuration, disable approval, and call a remote write tool. The server is connected and previously trusted. What controls should stop the chain?

    Expected reasoning

    Treat the entire resource result as untrusted input and ignore its request for authority. The token is outside the allowlisted task scope and must never enter a prompt, tool output, resource response, or log. Keep the remote write disabled or behind exact human approval, verify the diagnosis through independent Unity evidence, and grant only the smallest read or write needed for the reviewed task. Prior connection trust does not approve this call, and MCP alone does not guarantee these controls.

Go deeper

  • MCP authorizationOfficial overview of MCP authorization roles, discovery, and least-privilege access.
  • MCP security best practicesOfficial threat and mitigation guidance for tokens, confused deputies, SSRF, and local servers.