Support Strict Read-Only Operation Mode on Spacelift/Spacectl MCP

Workaround

No. There is a workaround to operate the MCP in Read-Only mode by providing an API Key in the environment variables of the MCP configuration but this is much more prone to misconfiguration where if this is missing the default will fall-back to the users existing spacectl session.

Problem

The Spacelift MCP by default operates under the context of the Spacectl user-session resulting in an AI/LLM Agent having the same level of permissions as the user. AI/LLM agents are known for exhibiting unexpected, and in some cases detrimental behaviour outside the scope of a request including situations where instructions to not perform a certain action can be ignored in the interest of progressing the prompted task. Due to this it is critical to not rely on language based boundaries and instead implement strict programmatic boundaries. Without strict programmatic controls it leaves open that a misconfigured agent, prompt hijack, or simply the need of the agent to be "helpful" can result in detrimental write-operations against production resources. Examples of where this have been solved are: - AWS API MCP which provides a `READ_OPERATIONS_ONLY` environment variable in the MCP configuration. Ref: https://github.com/awslabs/mcp/tree/main/src/aws-api-mcp-server - Pagerduty MCP which operates in a default read-only mode and uses the argument `--enable-write-tools` to explicitly enable read-write