Securing SitecoreAI Agents: Permissions, Tool Access, MCP Risk, and Governance Controls

Securing SitecoreAI agents requires control over the identity that executes each action, the tools available to the agent, the resources those tools can touch, and the approval needed before a consequential change. A useful deployment makes those boundaries explicit and tests them outside the language model. A prompt can describe the intended task. The application still needs to decide whether a particular operation is permitted.

Consider an illustrative task: a marketer asks an assistant to improve the copy on a campaign landing page. The intended result is a proposed edit to one page. The security design should answer what happens if the assistant selects another site, follows instructions embedded in a retrieved document, or attempts an unrelated deletion. A successful demonstration of the requested edit answers none of those questions. The negative cases deserve their own evidence.

Sitecore documents Marketer MCP as a connection between AI clients and SitecoreAI through the Agent API. That establishes the integration path; it does not describe the complete security posture of every client, model provider, or custom connector surrounding it. Sitecore’s Marketer MCP and Agent API overview explains that relationship.

This guide separates documented product behavior from a proposed implementation blueprint. Research was checked on October 5, 2026. The policy examples, approval records, test cases, and rollout gates below are recommendations for systems you control, not configuration syntax or guaranteed features of the managed Sitecore service. No production benchmark, customer incident, or hands-on tenant validation is claimed. Use the blueprint to identify what your actual tenant and chosen client enforce, then record the remaining gaps.

1. Map the agent’s trust boundaries before granting access

Start with the action path

Begin your design review with one representative task and follow it to the resource that changes. In the landing-page example, write down where the human request enters, which client builds the model context, how the client selects a tool, and which authenticated principal reaches the content API. Include any gateway or adapter your team adds. For each connection, identify the person responsible for its configuration and the evidence available when something fails. The result should be a diagram that an operator can use during an incident.

Then follow the data path in the opposite direction. Which page fields return to the client? Does the assistant receive unpublished material? Are uploaded briefs or retrieved assets included in the model context? Where can conversation history persist? Answer those questions for the concrete deployment rather than assuming a vendor’s platform boundaries also cover a separate AI client. Keep the diagram specific enough to show whether an internal document crosses into another service before any content mutation happens.

Record the trust level of every input. A request from the authenticated operator has a different role from text found inside a page or a third-party brief. A retrieved document can provide facts for the draft; it should not become a new authorization source. A tool result can report an item identifier; it should not grant permission to alter that item. Represent those distinctions in the application’s handling of inputs and in the review process, so they remain meaningful even when the assistant produces a plausible explanation.

Use a capability ledger

Create a ledger for each intended capability. For a campaign-copy assistant, the entry might say that it reads approved campaign source material, proposes changes to selected copy fields, and writes only after the required review. Attach the allowed site, content subtree, language, and environment to that entry. Also state what completion means. If completion means producing a draft for an editor, the ledger should not silently treat publishing, changing personalization rules, or removing old content as part of the task.

Give each capability an owner and an evidence requirement. The content owner decides whether the change is appropriate; the platform owner confirms that resource permissions match the intended scope. A security reviewer evaluates the extra connectors and data movement introduced by the client. These responsibilities can belong to the same person in a small team, but the record should still distinguish the decisions. Otherwise a statement such as “approved by the administrator” can hide whether anyone checked the actual change or only the connection setup.

For each capability, describe a concrete failure and a control you expect to stop it. For example, a request to change another brand’s landing page should fail at resource authorization. A change to a protected field should fail at field or application policy enforcement. A missing approval should prevent execution of the operation that requires it. If you cannot name an enforcement point, mark that capability as a design gap. Avoid recording “the model knows the rules” as equivalent evidence.

Separate content integrity from data exposure

A proposed copy change creates an integrity concern: the assistant might alter the wrong message or resource. Reading confidential source material creates a confidentiality concern even if the assistant has no write permission. Evaluate those concerns independently. A client approved for public campaign copy should not automatically receive private strategy documents. Likewise, an assistant that can read an appropriate source collection should not automatically receive permission to update all the content it encounters while researching the requested page.

For a custom retrieval integration, consider returning the smallest useful set of fields for the task. A summary job may need a title and a few approved body fields rather than complete raw responses. Build the filtering before content enters model context, and preserve enough provenance for reviewers to locate the original source. This is a proposed integration design, not a claim that Sitecore exposes a built-in filtering switch with these semantics. If your client cannot implement the restriction, narrow the source material you give it.

Environment boundaries deserve their own ledger entries. The same task in a test tenant and a production tenant can have different consequences. Record the selected organization and tenant as part of the run context, and display that context where operators start work. Treat a move to production as a separate approval decision, even when the agent instructions have not changed. That decision should review the destination resources and permissions rather than relying on the successful behavior of a previous demonstration.

Choose a narrow first use case

My preference is to start with an assistant that proposes edits to existing campaign text. It is easier to explain the intended resource scope and review the resulting difference than to govern an open-ended request to optimize an entire website. This is an architectural preference, not a measured performance claim. Another team may reasonably start with page creation if its templates and approval process are better controlled. The deciding question is whether the operation has a clear boundary and a practical recovery path.

Finish the mapping exercise with a short deployment contract. Name the use case, the authenticated execution identity, the data sources, the permitted resource set, and the required review. List every external service that can receive task data. Add the operator who can suspend the connection and the owner who can authorize reinstatement. That contract becomes the baseline for the permission review in the next section. Any later expansion should appear as a change to the contract, with supporting evidence, rather than as an unnoticed improvement to the prompt.

2. Design permissions around tasks and effective identities

Distinguish Agentic Studio permissions from content permissions

Agentic Studio has its own documented role and Builder-license matrix. Users and Editors can run agents. Editors can configure agents; a Builder license allows creating and duplicating custom agents for either role. The documented deletion permission is limited to an agent’s creator with a Builder license. These permissions concern agent management. They should not be interpreted as an unrestricted entitlement to act on every content resource. See Sitecore’s Agentic Studio user-management documentation.

Keep agent-definition changes in the same security conversation as execution access. A person who can alter an agent’s instructions or workflow can change what it attempts on future runs. For your deployment process, review those changes against the capability ledger. Ask whether a modification introduces a new input source, changes the intended destination, or encourages a broader action. Where the product does not enforce a separate definition-review process, document the operational process your team will use and who checks compliance.

Cloud Portal access is another layer. Sitecore states that Organization Admins and Organization Owners automatically receive the highest role in the organization’s apps. It also documents app roles and where administrative access must be changed. Inventory those relationships before connecting a privileged account to an AI client. Creating users in SitecoreAI is the relevant product reference.

Inspect effective access on representative resources

A role’s name is insufficient evidence of what an agent can do. Review the actual execution identity and the target items. Sitecore’s Access Viewer shows the combined result of access rights for an item and can explain workflow-related denials; using it requires the Sitecore Client Security role. Have an appropriately authorized administrator inspect the results. Consult Sitecore’s Access Viewer guidance instead of inferring access from an agent’s success message.

Build a sample set that includes an allowed campaign page, a nearby disallowed page, a shared datasource, and a protected item. If your use case crosses languages, include the relevant language variants. If it changes components, inspect the resources those components use. The sampling plan should reflect the task’s real dependencies rather than selecting only the easiest page to edit. Keep evidence of both permitted and denied outcomes so the review can distinguish an intentionally narrow account from an account that simply failed because of a configuration error.

For your integration design, derive the resource set from trusted deployment configuration and the authenticated user’s rights. Do not treat a model-supplied site identifier as the only proof of scope. Resolve a requested item against the approved destination before allowing a mutation. If you operate a custom policy layer, make its restrictions additive to the platform’s authorization. The extra layer should narrow what the agent can attempt; it should never substitute an administrator credential merely because the user’s request was denied.

Write permission cases as executable expectations

Express each permission case with a subject, action, and object. For example: the campaign operator may propose a change to the body field of the selected campaign page. The same operator may not change a shared legal-disclaimer datasource. Add the relevant environment and review condition. This format gives implementers something concrete to verify. It also exposes ambiguity when the task says “update the page” but the proposed change would actually affect a resource reused by several pages.

Use separate cases for viewing content and modifying it. An operator may need to inspect a shared component to understand a page without needing to edit that component. If you allow an assistant to prepare changes across several related resources, enumerate those resources in the proposal before execution. Require a fresh review when the proposed set expands. That operational rule prevents a narrow request from becoming a broad change merely because the assistant discovered more dependencies while working.

When a request is denied, preserve the denial reason in a form the operator can act on. A resource outside the approved campaign scope should produce a different diagnostic from an expired connection. Avoid instructing the assistant to try alternate identities or alternate API routes until something works. The appropriate next step is to resolve the missing entitlement through the responsible owner or revise the task to fit the available permission. A denial is part of the expected design, not a malfunction to route around.

Plan the identity lifecycle

Document whose authority is used for interactive runs and how that authority ends when the person leaves the team. For unattended integrations, first verify which authentication pattern the actual product and client support. Do not invent a Sitecore service-account flow from generic OAuth examples. If an application identity is supported in your chosen integration, give it its own narrowly justified capabilities and an accountable owner. The existence of an automation requirement does not establish that a broad shared administrator account is appropriate.

Review access changes together with active connections. Removing a person from a team, changing an app role, and withdrawing a client authorization may be distinct operational tasks in your environment. Establish which changes take effect immediately, which require reconnection, and which existing jobs need cancellation. Verify those behaviors in a nonproduction setting with the actual client. Record the result as deployment evidence rather than assuming that every layer handles revocation in the same way.

Finally, make permission review recurrent and event-driven. A new brand, a reorganized content tree, or a change to shared datasources can alter the practical scope of an existing role. Trigger a review when the deployment contract changes and when the platform owner changes relevant security configuration. The review should compare current effective access with the task ledger. If the account can now perform more operations than the task requires, decide whether to reduce the account’s rights or enforce a narrower agent boundary before continuing production use.

3. Govern tool access and validate every mutation

Inventory operations by consequence

The current Marketer MCP reference says its tools are enabled by default and recommends retaining them for full functionality. For a narrowly scoped enterprise agent, I prefer a smaller permitted action set where the chosen client or an approved integration layer can enforce it. That tradeoff may reduce convenience. Verify supported configuration rather than assuming a per-agent server-side allowlist exists. The product behavior is documented in the Marketer MCP tool reference.

Build your inventory from actual discovered tool definitions and current documentation. Classify each operation according to the information it returns and the state it can change. A read operation can still expose information outside the intended task. A small-looking edit can affect a shared resource. A deletion deserves a different review from creating a draft. Capture those consequences in the inventory instead of assuming that a tool’s name fully describes its security impact.

Two documented details deserve explicit review: update_content does not publish the item and creates a new version when updating an item in a Final or Approved workflow state. Conversely, delete_content deletes the entire content item regardless of the language parameter, which is currently unused, and may include children. These details come from the same tool reference. Do not generalize either behavior to every other mutation tool.

Specify an application policy, not just a tool list

A proposed policy for the campaign-copy assistant should restrict the allowed resources and fields as well as the operation. For a gateway you control, represent the selected tenant and campaign items in trusted configuration. Permit only the operations needed for that task, reject unexpected arguments, and require the relevant approval before a write. This is a custom application policy. It is not a drop-in Sitecore configuration file, and it should be implemented only through supported integration paths that preserve platform authorization.

{
  "policyId": "campaign-copy-v1",
  "defaultDecision": "deny",
  "tenantRef": "configured-tenant",
  "approvedItemRefs": ["selected-campaign-page"],
  "allowedOperations": ["read-selected-copy", "propose-copy-change"],
  "writableFieldRefs": ["approved-body-field"],
  "executionRequires": "approved-exact-proposal",
  "maxItemsPerProposal": 1,
  "allowDeletion": false
}

This JSON is an illustrative policy contract. Its operation names and property names belong to the example, not to the Agent API or a native MCP schema. An implementation must translate approved application actions into the real supported endpoint and tool arguments. Keeping that distinction explicit helps reviewers see which parts of the design are backed by the product and which parts require code, client settings, or operational controls owned by the deploying team.

Do not use hiding a tool in the interface as your only enforcement. In a custom system, test the execution boundary with a direct prohibited request. If a request can reach another endpoint using the same credentials, determine which policy applies there. The application owner should document every path that can execute an operation, including alternative clients used by the same people. A narrow agent experience is useful, but its restriction must hold where the operation is performed.

Validate resource meaning and proposed values

For a proposed copy edit, first resolve the target against the approved item set. Then validate that the intended language and field match the deployment contract. Reject unknown fields rather than dropping them silently. If a request includes a resource that the agent discovered during research, treat that addition as a scope change. The assistant can explain why the resource might need attention, but the explanation should not add it to the allowed set automatically.

Validate the proposed values according to their destination. Plain text, rich text, component settings, and URLs need different treatment. Do not send generated output directly into another interpreter or executable context. OWASP’s Improper Output Handling guidance identifies inadequate validation and encoding of model output as an application risk. In your copy workflow, apply the same content rules used for an editor’s submission, with additional checks for any links or embedded structures the task does not require.

Define a maximum mutation scope that matches the business task. The illustrative policy above allows one item because this example concerns a selected campaign page; that number is a proposed restriction, not an industry benchmark. A batch-localization task could justify a different bound. Require an explicit list of intended targets before a batch executes, and give reviewers a way to exclude individual changes. If the assistant cannot enumerate the affected set, keep the work at the proposal stage.

Handle state changes and retries deliberately

Have the custom execution layer confirm that the approved proposal still matches the current resource state. A reviewer should not approve one version and later execute a materially different proposal. Where the supported API exposes suitable concurrency controls, use them. Otherwise establish a documented application-level comparison and review process, and be honest about the race conditions it cannot eliminate. Do not invent an ETag, transaction guarantee, or idempotency feature that the actual endpoint does not document.

Plan for an ambiguous response after a mutation. A timeout can leave the operator unsure whether the change occurred. Before retrying, use the supported read path to inspect the target and reconcile the intended change with its actual state. For your custom job service, track a stable operation reference and the result of each attempt. Those records help prevent a recovery action from creating an unintended second resource or repeating a destructive operation. Verify the real endpoint’s retry behavior during validation.

Use a completion report that distinguishes a proposed change, a saved change, and an externally visible result. Confirm the resource state using supported reads or previews instead of relying on the assistant’s narrative. Report unresolved operations as unresolved. For this deployment contract, completion means a reviewed draft in the selected scope; publication is a separate task with its own decision. A clear report gives the operator an accurate next step and provides evidence for the audit trail.

4. Contain prompt injection and MCP integration risk

Treat retrieved instructions as untrusted content

OWASP distinguishes direct prompt injection from indirect injection through external material such as websites or files. It also notes that retrieval and fine-tuning do not fully remove this risk. That is a reason to enforce permissions and action boundaries independently of the model’s interpretation. See OWASP’s Prompt Injection guidance. The operational scenarios below are illustrative tests proposed for this article; they are not reported Sitecore incidents.

Imagine that the campaign assistant retrieves a brief containing a sentence that tells it to ignore the operator and remove a different campaign. The correct security outcome does not depend on proving that the model will always recognize the instruction. Your design should prevent that deletion because it is outside the task’s permitted operations and resources. Preserve the suspicious source reference for review, but do not turn the retrieved sentence into an instruction with the same authority as the authenticated operator’s request.

Test subtler cases as well. A retrieved page could claim that a second tool must be called to verify a citation. A tool response could claim that an administrator already approved a broader change. A source document could ask the assistant to send internal copy to an external address. In your test environment, verify that such claims do not establish authority or destination approval. Approval should come from the authenticated approval process, and outbound destinations should come from the deployment policy.

Review MCP as a connection to a larger system

Sitecore describes Marketer MCP as using authentication, tenant isolation, short-lived tokens, permission checks, and audit logging. Its actions remain subject to the user’s permissions and applicable workflows; data handling also depends on the AI client, provider, and deployment configuration. These are documented platform boundaries, not proof that every surrounding integration is safe. Read the security and governance notes in the Marketer MCP reference.

Inventory every server connected to the chosen client. For each, identify its operator, why the task needs it, what credentials it receives, and what task data may reach it. A campaign assistant that also connects to a document store or an outbound messaging service needs a review of the combined workflow. Do not approve each connection in isolation and assume the composition has the same boundary. The review should follow how information from one source could influence an action in another connected system.

For a remote connection, verify its endpoint against the official setup documentation and your approved connector record. Sitecore’s setup guide lists https://marketer.sitecorecloud.io/mcp/marketer-mcp-prod for new configurations and describes selecting an organization and tenant during connection. Capture the selected context in your deployment evidence. The guide also identifies a previous endpoint as being deprecated. Consult Sitecore’s Marketer MCP setup documentation when configuring or reviewing the connection.

Use the protocol guidance for components you implement

The MCP authorization specification requires a server to validate tokens for its intended audience and reject invalid or expired tokens. Its security guidance prohibits token passthrough and discusses confused-deputy attacks, SSRF, and local-server compromise. These requirements and risks guide components you implement or select. They do not establish which protocol revision a particular Sitecore deployment supports. Refer to the MCP authorization specification and MCP security best practices.

If your team owns a custom MCP adapter, define its credential boundaries explicitly. Record which service issues each credential, which resource accepts it, and how the adapter authenticates to downstream services through the supported mechanism. Test rejection of a credential intended for a different resource. Do not assume that possessing a token is sufficient evidence that it is appropriate for every API the adapter can reach. Keep secrets outside the prompt and outside diagnostic content sent to the model.

If your client performs network discovery or your custom tools fetch URLs, review the destinations those components can reach. For an application you control, restrict outbound access to the approved destinations needed for the task and validate redirect behavior. Test with a harmless controlled endpoint representing a prohibited destination. Avoid using a production internal service as the test target. Where you rely on a managed client, request evidence of its relevant protections rather than claiming you have configured controls that the client does not expose.

Review local execution and connector changes

A local connector introduces a different operational question from a remote service: what process runs on the operator’s machine and with what access? For your approved client configuration, record the installed package, its publisher, its version or integrity reference where available, and the reason it is needed. Review its access to local files and environment variables. If the task only needs the official remote connection, require a separate justification before adding local executable components.

Capture a baseline of the tool definitions and configuration that were reviewed. When a connector update changes an operation’s arguments, description, or result format, assess whether the capability ledger and tests still apply. In a custom deployment pipeline, require review before activating materially changed capabilities. For a managed service whose tool definitions can evolve outside your release process, establish a supported detection and review practice. Do not imply that freezing a local manifest prevents every upstream change.

Finally, test secret exposure as its own failure class. OWASP’s System Prompt Leakage guidance warns against putting credentials in prompts or treating prompts as security controls. Use synthetic secrets when checking your handling of logs and tool results. The exercise should demonstrate that sensitive values are excluded from model-visible diagnostics and routine telemetry. If a value appears where it should not, repair the data path before giving the agent more sources or actions.

5. Make governance observable and approvals specific

Connect governance to an operational decision

NIST’s AI Risk Management Framework organizes risk work into Govern, Map, Measure, and Manage, with governance spanning the other functions. Its guidance is voluntary and intended to be adapted to the use case. Use it to structure responsibility and evidence rather than claiming that a framework reference certifies a deployment. See the AI RMF Core and the NIST AI RMF Playbook.

For the campaign assistant, map those functions to concrete records. The deployment contract names the accountable owner and permitted task. The trust-boundary ledger identifies the data and action paths. A test report measures whether required boundaries hold. A release decision states whether the remaining gaps are acceptable for the chosen use case. This mapping is a proposed operating model for the example, not a mandatory NIST checklist. Its value is that each governance statement has an owner and an observable result.

Keep product governance and business governance connected. A platform may correctly authorize a write while the proposed copy is commercially inappropriate or factually wrong. A reviewer may like the copy while the agent is using an unnecessarily broad identity. The release process should cover both decisions. Give content reviewers the proposed changes and source references, and give platform reviewers the execution scope and technical evidence. Neither review should be represented as automatically satisfying the other.

Approve the exact change

For a custom approval service, create a proposal record before the operation that requires approval. Include the selected destination, affected resources, proposed values, and current resource state used to prepare the change. Bind the approval to that record and to the authenticated reviewer. If the assistant revises the proposal, treat the revision as a new reviewable object. A general message such as “go ahead with the campaign” should not become an unlimited authorization for whatever the assistant later decides to do.

{
  "proposalId": "example-proposal-001",
  "runId": "example-run-001",
  "policyId": "campaign-copy-v1",
  "tenantRef": "configured-tenant",
  "itemRef": "selected-campaign-page",
  "languageRef": "approved-language",
  "fieldRefs": ["approved-body-field"],
  "baseStateDigest": "digest-of-reviewed-state",
  "changeDigest": "digest-of-canonical-proposal",
  "approvalStatus": "pending"
}

This is an illustrative record for a service you would build, not a Sitecore API payload. The digests are placeholders, not working values. An implementation needs an agreed canonical representation and trusted storage for both the proposal and the decision. It must authenticate reviewers, enforce their approval rights, and compare the approved proposal with what execution will submit. A digest alone does not prove that the correct person reviewed the content or that the stored record is trustworthy.

Design the review screen around the consequences. Show the destination and the complete affected-resource set, then display the changed fields and any relevant previews. Make unexpected scope expansion visible. For a shared datasource, show the known reuse information available through supported inspection. If you cannot determine the affected consumers, state that uncertainty in the proposal. The reviewer should not have to infer the resource footprint from the assistant’s summary or from a friendly title.

Make human review practical

My preference is to separate proposal generation from the consequential execution step for early deployments. It gives reviewers a stable artifact to inspect and makes it easier to stop a run without guessing which writes already occurred. That preference adds workflow overhead, so it should be revisited when the team has evidence about the task’s reliability and recovery. Do not use the desire to remove clicks as the sole reason to grant broader autonomy.

Avoid turning review into a routine approval queue that obscures the change. Limit proposal size to what the assigned reviewer can assess. Route unusual operations to the owner who understands them. A copy editor may be the correct reviewer for text but not for a change to a targeting rule. When a proposal mixes these concerns, divide it into reviewable units or require the appropriate additional review. The governance record should identify who accepted each consequence.

State what happens when review cannot be completed. An unavailable approver, an unreadable preview, or a missing source should leave the relevant operation pending. In a custom application, make that behavior explicit rather than treating a timeout as implied consent. If the business needs an emergency path, define it separately with a named operator and a bounded scope. Test that the emergency path does not silently become the normal route for every failed approval.

Preserve evidence without collecting unnecessary content

For your custom observability layer, correlate the human request, proposal, policy decision, tool invocation, and confirmed resource result. Record the effective principal and destination context using identifiers appropriate to your privacy requirements. Keep the tool and policy revisions that explain the decision. Distinguish denials, failed attempts, confirmed writes, and uncertain outcomes. This event design is proposed instrumentation; the exact managed Sitecore audit fields and export options must be verified in the deployment.

Exclude credentials and unnecessary sensitive payloads from routine logs. OWASP’s Logging Cheat Sheet recommends application-level security logging and identifies information that should be excluded or handled carefully. For the campaign workflow, store protected proposal content only where the reviewers need it, and use references in general telemetry. Define retention and log access with the people responsible for the underlying data. More logging is not automatically better evidence if it creates another uncontrolled copy of confidential material.

Build an incident query before production rollout. An operator should be able to answer which resources a particular run changed, which proposal authorized those changes, and whether any outcomes remain unresolved. Test the query using the pilot’s records. Also confirm that the owner can suspend future execution through the supported control path. The governance system earns its place when it makes a specific release, investigation, or recovery decision easier to execute.

6. Validate the controls and roll out a bounded agent

Test denied actions alongside successful tasks

Before rollout, write a small test plan around the deployment contract. Include an allowed edit to the selected campaign page and several prohibited changes. Exercise the tests with the actual client, connector, identity, and environment used for the pilot. Keep integration-layer tests separate from platform permission tests so the report explains which boundary caused each denial. An expected refusal in the assistant’s prose is useful behavior, but verify the resource result as well.

OWASP recommends denying by default and checking authorization on every request. Its Authorization Cheat Sheet provides the baseline for an application policy layer. Apply that principle to the custom execution service and test every protected path you expose. If a path cannot enforce the agreed boundary, remove it from the pilot’s capability set or hold the corresponding capability until the gap is resolved.

The table is a proposed acceptance plan, not a set of observed results. Define the precise expected outcome for your implementation before running each case. Use dedicated test resources and synthetic data for adversarial inputs. Record the connector and policy revisions alongside the result. If a case passes only because the model happened to refuse the request, also exercise the relevant enforcement point directly through your controlled test path. That distinction prevents a behavioral success from being mistaken for proof of authorization.

Use an end-to-end campaign exercise

Run one complete illustrative campaign task in a nonproduction environment. The operator selects a page and supplies an approved brief. The assistant reads the permitted inputs and prepares a proposal. The reviewer inspects the diff and approves the exact artifact. Execution checks current authorization and the approved resource state, then submits the supported mutation. Finally, the operator verifies the saved result through the platform’s supported inspection path. Keep the report focused on observable outcomes rather than the assistant’s confidence.

Repeat the exercise with the smallest meaningful variation. Replace the selected item with an out-of-scope item, add a prohibited field, or modify the proposal after approval. These variations should produce the outcomes specified in the acceptance plan. If the client does not expose a way to exercise a particular boundary, identify that limitation and test the component you control. Do not present a test of a custom gateway as a validation of every behavior in the managed platform.

For each failure, decide whether the remedy belongs in platform permissions, custom application policy, client configuration, or the operating process. Avoid solving every problem by adding another sentence to the agent instructions. Some failures may be content-quality problems that need clearer source material or review criteria. Others reveal an execution path with too much authority. Keep those findings distinct so the fix addresses the boundary that actually failed.

Set release gates you can defend

For the initial pilot, require a named owner, an approved data path, a reviewed permission set, and evidence that the required denial cases hold. Also require a tested way to suspend future runs and reconcile an incomplete run. The exact release criteria should match the business consequences of the task. A public copy suggestion and a production change to a shared content resource should not receive identical evidence requirements simply because both originate in the same chat interface.

Use explicit rollout stages. First validate the bounded task with test content. Next let selected operators generate proposals against approved resources under the established review process. Expand write access only when the execution and recovery controls have evidence. Any later move to more resources or broader autonomy should update the deployment contract and tests. These stages are a recommended sequence for this example, not a claim that Sitecore provides a native rollout wizard implementing them.

Define useful measurements before collecting them. For example, measure the proportion of proposals reviewers accept without editing, the number of confirmed out-of-scope mutation attempts, and the time operators need to reconcile uncertain outcomes. Specify the denominator, observation period, and collection method for each measure. No numerical results are asserted here. The purpose is to make your own pilot evidence interpretable and to avoid comparing unrelated success rates from different tasks or approval conditions.

Prepare recovery and expansion decisions

Write a runbook for a wrong but authorized change. Identify the supported way to restore or correct the affected resource, who reviews the repair, and how you confirm the resulting state. Keep recovery separate from stopping future execution: suspending a connection does not itself repair an earlier content change. Test the runbook with disposable resources. Where restoration has limitations, record them in the release decision and avoid granting operations whose consequences the team cannot manage.

For a suspected credential or connector problem, establish the supported actions for withdrawing access and reviewing affected runs. Assign an operator to preserve the available evidence and identify uncertain outcomes. Confirm recovery through the actual client and platform rather than assuming a generic token-rotation procedure applies to every integration. Before reinstatement, revisit the deployment contract and the failed test case. A resumed connection should reflect a resolved finding, not merely a restarted process.

Questions to settle before expanding autonomy

Does connecting an AI client grant extra Sitecore permissions? The documented Marketer MCP model uses the user’s existing permissions. In your deployment, verify the effective execution identity and avoid custom adapters that substitute broader authority. Treat agent-management permissions, app access, and resource authorization as distinct review points.

Can a prompt guarantee that only the intended resources change? Use instructions to define the task, then verify resource and operation restrictions at the enforcement points. For the proposed campaign workflow, the resource set comes from the approved deployment context and exact proposal. A model-generated justification cannot enlarge that set.

When should a human approve a change? For this initial deployment, review the proposal before the consequential operation. Select the approval rule according to the resource’s business impact and the recovery evidence. Bind the decision to the exact artifact so later revisions cannot inherit an unrelated approval.

What should be the next practical step? Choose one campaign task, document its identity and resource scope, and run the acceptance cases above in a suitable test environment. Keep publication and destructive operations outside that first capability contract unless the task explicitly needs them and you can defend their controls. Expand only after the owner can explain what is permitted, what is blocked, and how a failed run will be recovered.