AI-native IDE
Deployment Security
Controlled access. Protected instructions. Traceable execution.
Architecture deployments may involve sensitive infrastructure information and operations that affect running systems.
SPECTRALE is designed to separate the user's architectural intent, the agent's authorization, and the agent's actual execution permissions.
This page explains the main security boundaries of the AI-native IDE.
Security architecture at a glance
- Architecture draft
- Deployment authorization
- Protected manifest storage
- Authenticated MCP access
- Authorized agent
- Execution and verification
Authorization and instruction protection are separate layers. A connected agent still needs its own permission to change the target environment.
1. Agent authentication
Before an AI agent can access protected deployment functionality, it must authenticate through the supported MCP connection mechanism.
SPECTRALE MCP uses OAuth, including authorization-code grants with PKCE, and bearer tokens on later requests.
Authentication establishes the credential context of the connecting agent. The server validates the presented credentials.
An unauthenticated connection cannot retrieve protected deployment instructions.
2. Project and deployment authorization
Authentication alone is not sufficient.
SPECTRALE also verifies that the authenticated agent is authorized for the requested project and for that specific deployment.
A deployment is visible to an agent only when it is assigned to that agent connection and the project is inside the connection's authorization scope. Access to one project does not imply access to unrelated projects.
Knowing a deployment identifier is not enough. If the deployment is not assigned to the calling connection, the server responds as if the deployment does not exist rather than returning its instructions.
Reading the manifest also requires the same connection to have claimed the deployment, and the deployment must be in a status that allows instruction access.
Authorization is enforced by the SPECTRALE backend, not only by hiding interface controls.
3. Protected deployment instructions
SPECTRALE uses structured Architecture Change Manifests to describe deployment instructions.
Because these manifests may contain sensitive architecture information, storage and delivery are controlled separately from ordinary architecture browsing.
Encryption at rest
The implemented protection is authenticated envelope encryption. When an external key service is configured, each manifest receives a fresh 256-bit data key. The canonical manifest is encrypted with AES-256-GCM and a fresh nonce. Associated data binds the ciphertext to the schema, project, deployment, and manifest identifier. The data key is wrapped by the configured key service. The supported external provider is AWS KMS, using that environment's cloud credential chain rather than a key stored in the application configuration.
That encryption is not applied to every environment. If no key service is configured, and the environment does not require encryption, the canonical manifest is stored pending encryption. Those records are not ciphertext and should not be described as encrypted. If an environment requires encryption and no key service is available, manifest creation is refused instead of falling back to plaintext.
The production environment currently refuses to create architecture change manifests. Envelope encryption is therefore not live in production.
Identifiers needed for authorization and indexing remain outside the ciphertext: the manifest identifier, schema version, project and deployment binding, protection state, and the SHA-256 digest. When a manifest is encrypted, the plaintext document is not stored beside the envelope. When it is pending encryption, the canonical document is stored so the authorized workflow can still open it.
The design can rewrap an existing data key under a new key-encryption key without rewriting the ciphertext. That capability is not the same as an active key-rotation schedule. Rotation only happens where an operator configures and runs it.
Encryption in transit
Protected deployment information is transmitted over HTTPS. The public MCP endpoint is served with TLS.
Transport encryption and encryption at rest serve different purposes. HTTPS does not turn a pending-encryption record into ciphertext at rest, and encryption at rest does not replace TLS.
Authorized manifest access
The backend validates the agent's authentication, project grant, deployment assignment, and claim before it opens the instruction content.
When the manifest is encrypted, the server unwraps the data key and decrypts the payload in order to deliver it to that authorized agent. SPECTRALE can therefore read the instructions it stores. This is not end-to-end encryption, and it is not a design in which only the external agent can decrypt the manifest.
Manifest integrity
Every manifest stores the SHA-256 digest of its canonical JSON. Opening a manifest checks that digest. When envelope encryption is in use, the AES-GCM authentication tag also detects modification of the ciphertext or its bound context.
A digest shows whether the stored bytes still match the canonical document. It does not, by itself, prove who authored the manifest.
4. Separation of responsibilities
SPECTRALE controls:
- Architecture draft management
- Deployment request creation
- Manifest storage and access
- Agent authorization
- Deployment coordination
- Progress and result records
The connected agent controls its execution process and uses the external permissions available to it.
This separation helps make deployment responsibilities explicit.
It does not eliminate the need to secure the external agent, its credentials, and the target infrastructure.
5. Sensitive information and secrets
Deployment instructions and deployment conversations reject content that matches secret material, including embedded credentials and private keys.
Agents should obtain required execution credentials through appropriate secure mechanisms rather than receiving raw secrets inside architecture descriptions.
Do not place secret values in deployment notes, conversation messages, or architecture labels.
6. Destructive operations
Some architectural operations can be destructive or disruptive.
Examples may include removing components, disconnecting dependencies, or changing infrastructure configuration.
When validation reports warnings, or when a manifest operation requires preflight, SPECTRALE refuses to create the deployment until the user acknowledges those risks.
Acknowledgement is a confirmation gate. It does not make a destructive change reversible, and it does not execute the change itself. The agent still has to carry the operation out with its own tools.
7. Auditability and deployment history
Deployment records and agent conversations help users understand:
- What was requested
- Which agent was selected
- What progress was reported
- Whether execution completed or failed
- What verification results were observed
Manifest reads by an agent are recorded with the manifest digest, protection state, and connection. These records improve traceability but do not replace external infrastructure audit logs.
Security boundaries and limitations
Important security boundary. SPECTRALE can authenticate and authorize access to deployment instructions, but the external agent remains responsible for actions performed with its own tools and credentials. Encryption protects information within its defined storage and transport boundaries. It does not prevent an authorized agent from acting on instructions or from exposing information through an insecure external environment.
Use the controls above as the source of truth. Envelope encryption, key wrapping, and production manifest creation depend on environment configuration. Where those controls are not enabled, the documentation does not treat them as active.