Audit your GTM stack before granting agent access

Define the workflow's beginning and end. For account research, begin with an authorized CRM account ID and end with a cited summary plus a proposed note. Exclude owner reassignment, stage changes, sequence enrollment, external messages, and paid enrichment from the initial permission grant. Those actions need their own release decisions. Do not let a vague instruction to 'complete the research' authorize an unlisted endpoint. The approved job describes what users receive and which systems remain unchanged.

Classify actions by consequences rather than HTTP method or tool name. A retrieval can expose restricted data or consume paid credits. A draft save is a write even if nobody receives an email. A purchase combines spend and a persistent external change. Mark all applicable categories on each action. Default unclassified operations to unavailable. A newly discovered connector tool must enter the permission register before the agent can call it.

Create permission_id, workflow_id, system_id, operation_name, endpoint_version, action_classes, allowed_fields, target_scope, data_classification, provider_account_id, credential_owner, granted_scopes, approver_role, spend_limit, currency, retention_rule, and rollback_owner. Use action_classes values read, write, send, and spend. Store denied operations explicitly. Attach evidence_ref and reviewed_at to each row so a permission entry can be traced to a real connector inspection rather than a product homepage.

An execution proposal adds proposal_id, requesting_user_id, tenant_id, record_id, record_version, proposed_payload, payload_digest, evidence_refs, estimated_cost, approval_id, approval_expires_at, approval_consumed_at, execution_attempt_id, and execution_status. Use proposed, denied, approved, executing, executed, failed, and outcome_unknown as statuses. Approval binds actor, operation version, tenant, provider account, target, normalized payload, and expiry. A hypothetical research_note property update uses permission_id=research-note-v1, record_id=acct_204, allowed_fields=research_note, and action_classes=write. Name the actual CRM object and update endpoint in the permission row. This grant does not create a note activity, change ownership, or send a message.

Export the actual connected tools and credentials for the workflow. For each operation, compare the business permission with the provider scopes and the fields the endpoint accepts. HubSpot's contact guide lists crm.objects.contacts.read and crm.objects.contacts.write separately. It also describes record retrieval and contact-property operations. Use that distinction as a concrete inspection case. Do not infer that an account-wide write scope restricts itself to your chosen research field.[1]

Create a permission matrix where account research can read approved account facts, note preparation can propose a change, and the controlled executor can write only the approved note. Keep send=false and spend=false for that workflow. Remove unnecessary tools from discovery and enforce the remaining operations in the execution service. If the provider's credential cannot be narrowed to one field, document the residual access and restrict your executor's field allowlist. Security must accept that residual access rather than treating the allowlist as a provider guarantee.

Acceptance requires a permission row for every exposed action and an owner for every credential. Personal administrator tokens and hidden paid fallbacks fail the initial grant. Give the revenue owner a readable permitted-action and denied-action list.

Assign one authority for each field the workflow consumes or proposes. Keep CRM account identity and ownership in the CRM. Assign the suppression decision to the existing permission service, not to an agent's research output. Give each cited research fact a source reference and observation date. Separate an observed claim, a seller-approved interpretation, and an authoritative CRM value. A summary that calls an account 'high priority' must not silently alter a territory assignment.

Use tenant_id plus system_id plus record_id as the record key. Maintain an explicit account-to-domain mapping with parent, subsidiary, and alias relationships. Do not merge two records solely because they share a website or a contact email. Keep merge proposals outside the initial write grant. When a contact changes employers, preserve the distinct person and account references. For an ambiguous match, return a review card showing candidates rather than writing to the most similar name.

Acceptance requires a synthetic parent account, subsidiary, duplicate display name, and moved contact to produce distinct targets or explicit ambiguity. The AE sees the account ID and current owner on the proposal. The CS manager sees the customer account boundary rather than an inferred group-wide relationship. Re-read the authoritative record before applying an approved change. If a relevant field changed after review, reject the proposal as stale and request a new approval.

Record the provider-side identity, tenant, connection ID, credential owner, authentication method, granted scopes, and installed tool version. Verify the provider identity with an authorized read in your nonproduction environment. Do not trust an account alias alone. Composio documents that sessions can pin connected account IDs. Its multi-account options include explicit selection, and the default can select the most recently connected active account. Review that configuration rather than assuming a work-account label fixes execution identity.[3]

Inspect connection expiry, revoked access, pagination, partial responses, rate-limit handling, and ambiguous write outcomes as separate cases. Do not interpret an empty response as proof that the CRM has no matching record. For writes, define a provider-specific reconciliation read. If a timeout leaves the outcome unknown, block a second execution until reconciliation resolves the first action. Store the provider receipt when available. Do not claim exactly-once behavior unless the chosen operation actually supplies the required mechanism and your team has exercised it.

Acceptance requires stable account selection when another account connects and failure without identity switching after revocation. Schema changes must stop unsupported operations. Retain the tool definition, version, scope inspection, and observed failures. Vendor documentation is not deployment evidence.

Route a CRM note to the account owner or authorized delegate. Route an external send to the sender and required policy reviewer. Route a paid call to the budget owner. Keep these decisions distinct. n8n documents human review for selected AI tools, with approval executing the specified input and denial canceling the action. Use the review interface to display the proposed tool and parameters, then enforce your tenant, target, expiry, and payload binding in the executor.[2]

Show the reviewer the target, current and proposed values, evidence, provider account, cost, and any external recipient. An edit invalidates approval. Immediately before dispatch, atomically claim approved to executing for the proposal and approval, recording approval_consumed_at and execution_attempt_id. Only the successful claimant dispatches. Keep the claim consumed during outcome_unknown. A reconciliation read that proves success returns the existing receipt without another dispatch. An evidenced failure needs an explicit retry decision and the operation's documented idempotency behavior. A spend grant also binds a maximum amount and currency, not just an estimate.

Acceptance requires denial, expired approval, and changed payload to leave the target unchanged. Submit two concurrent requests with the same approval. Require one provider dispatch and a visible duplicate rejection. Replay the consumed approval after success and require the existing receipt or a rejection, never another dispatch. Confirm the destination record and show its receipt to the AE. A green approval card is not proof that the CRM accepted the write. Keep send and spend disabled until their separate acceptance cases pass.

Treat websites, email bodies, CRM notes, and retrieved documents as untrusted input. OWASP describes indirect prompt injection through these sources and warns that prompt labels do not provide an enforcement boundary. Keep secrets out of retrieved context. Make the execution service check operation, caller, target, field allowlist, and approval without asking the model whether its proposed action is safe. A research page that asks the agent to export contacts must never expand the permission grant.[4]

For MCP connections, review the authorization boundary as well as the business permission. MCP security guidance forbids token passthrough and requires tokens accepted by the server to be issued for that server. Its confused-deputy guidance requires per-client consent and validated redirects for the described proxy flow. Have security inspect the actual implementation and credential custody. A connector's ability to list tools is not evidence that its authorization configuration satisfies those requirements.[5]

Acceptance requires a synthetic research document containing an instruction to change account ownership to leave ownership unchanged. Also attempt cross-tenant retrieval, a forbidden field write, and an unapproved recipient substitution. Reject all four at the execution boundary and retain the rejection reasons. Report a successful denial without copying credentials or sensitive payloads into the seller-facing receipt.

Name each case and its expected destination state. 'Wrong connected account' must stop before retrieval. 'Duplicate account name' must return ambiguity. 'Owner changes after approval' must reject the stale proposal. 'Injected source requests contact export' must produce no export. 'Timeout after accepted write' must enter outcome_unknown until reconciliation. 'Budget approval absent' must block paid calls. Use synthetic inputs and retain actual outcomes when your team runs the cases. These are acceptance requirements, not results claimed by this article.

Require consumer-visible proof as well as backend evidence. The AE sees the rejected proposal and the corrective action. The CRM administrator inspects unchanged restricted fields. Security sees which identity attempted the action and why the executor denied it. Do not hide failed actions behind a completed research summary or replace an unavailable paid source with fabricated data.

Do not require identical model wording to declare a run correct. Require stable record identity, allowed action class, approved field set, evidence references, and destination state. Freeze synthetic input records and expected permission decisions in a release fixture. Capture the connector version, policy version, and proposal receipt for each run. A valid summary can vary in wording while the write target and authorization decision remain fixed.

Any forbidden write, cross-tenant access, approval bypass, or unapproved spend blocks release. Score research usefulness separately for source support and missing facts. A usefulness score cannot compensate for failed permissions. Require the CRM and security owners to sign the same evidence pack.

Calculate permission coverage as exposed operations with approved register rows divided by all exposed operations, in percent. Calculate identity coverage as active connections with verified provider account, tenant, and owner divided by all active connections. Calculate approval integrity as executed consequential actions with a valid exact-payload approval divided by all executed consequential actions. Include manual executor paths in that denominator. Calculate reconciliation completeness as outcome_unknown actions resolved to an evidenced destination state divided by all outcome_unknown actions.

Report unauthorized executions as a count and as unauthorized executions divided by all execution attempts. Report paid cost per accepted packet as actual invoiced or metered workflow cost divided by packets the reviewer accepted, in the stated currency. Keep rejected and unresolved costs in the numerator. These measurements guide your release review. They are not performance promises, a prescribed analytics implementation, or evidence that any vendor meets your policy.

Release read-only research to a small authorized group after identity and permission gates pass. Promote reviewed notes after the negative cases pass. Sending and paid calls need separate grants. Revenue signs usefulness, CRM administration signs field ownership, and security signs execution controls. The workflow owner records the versioned release and denied capabilities.

Name the workflow and connection revocation owners. Pause on authorization mismatch, unintended changes, missing approval receipts, or connector drift. Reconcile pending writes before restart. The record owner must review corrections against current state, including subsequent user edits. Public documentation was reviewed on 2026-10-14. No connector was authenticated or runtime-tested here. Supply deployment evidence before granting access.