Security best practices to build with AI

Ask about this Page
Copy for LLM
View as Markdown

Key security considerations for building with AI agents on commercetools.

Building with AI agents changes the threat surface. The agent reads your project, writes code, and, if you let it, calls your live APIs. The principle of shared responsibility applies: the skills steer the agent toward secure defaults, but a human reviews and owns every line that ships.

Credentials

Use a Frontend API client for the storefront, never a manage_project API client. This is the most important point of all, so grant the storefront client only the scopes it needs and nothing more.

Keep the following in mind:

  • If a client has manage_project in its scopes, do not proceed. It should never be deployed to a public storefront.
  • The manage_my_* scopes are also not suitable for this architecture.
  • For B2C, the minimum set is built around viewing published products and categories, managing Carts, Orders, Customers, and Sessions, and handling shipping, not administering the Project.
Keep credentials off the browser entirely. Thanks to the backend-for-frontend boundary, secrets live only in the .env file on the server, where Route Handlers read them, and there are no NEXT_PUBLIC_ secrets.
If you spot a commercetools secret in a NEXT_PUBLIC_ variable, fix it immediately. Use separate clients per environment so a leaked development credential can't reach production data.
Set a strong session secret of at least 32 characters, generated with openssl rand -base64 48, and never commit it. Keep any administrator-scoped credentials you used for setup scripts out of your Vercel and Netlify environment variables.

MCP server security

The two bundled MCP servers carry very different risk:

ServerRiskWhat to do
commercetools-knowledgeLow. Read-only and public, reads only docs and schemas.Safe to leave on all the time.
commerce-mcpHigh. Acts with your credentials against your project.Use minimum scope, set it to read-only for exploratory work, use write access only when a task needs it, and keep a record of what the agent did.

Prompt and data hygiene

Don't paste production data into prompts. Personally identifiable information, real order details, and payment data don't belong in a prompt. This holds even when you're just showing the agent an example. Use synthetic or anonymized data instead. Be specific about scope. A prompt with a narrow scope produces code with a narrow scope. An open-ended prompt invites the agent to change more of the system than you intended.

Reviewing what the agent writes

The agent writes the code, but your team owns it. You need to carefully check the following in the code that the agent wrote:

  • Secrets in committed files: anything that looks like a credential in .env files, config, or source, and make sure .env files are git-ignored.
  • Scope creep: cases where the agent reached for a broader scope or a more powerful API than the task needed.
  • New dependencies: what the agent added to package.json and why.
  • Server-side enforcement: security rules enforced on the server, not just in the UI. Hiding a control in the interface is a courtesy, not a boundary, so anything sensitive like a price override has to be guarded server-side.

Before you go live

Before going into production, check that the following conditions apply:

  • The storefront uses a Frontend API client, with no manage_project scope anywhere in the deployed environment.
  • SESSION_SECRET is set, unique per environment, and at least 32 characters long.
  • No NEXT_PUBLIC_ secrets in .env file on the server.
  • No .env files were committed to Git, and secret scanning is active in the CI.
  • Admin and tooling credentials aren't stored in the deploy environment.
  • Dependency audit run on what the agent installed.
  • commerce-mcp was reviewed to ensure minimal scope, with write permissions granted only where necessary.
  • Real human review and functional testing was done, because the agent's own checklist is a starting point, not a sign-off.