Connected AI agents: approve each tool action with a capability manifest

An AI agent connected to a CRM, ticketing system, document store, or internal API should not inherit a broad service account simply because a connector is available. Choose access per action, resource, user context, and time window. Start read-only, expose a narrowly scoped write operation only when the workflow requires it, and put consequential or hard-to-reverse actions behind a separate approval boundary.

That is the practical answer to a deceptively simple question: “Can an AI agent connect to my existing software?” A connector is not just a pipe. It is a delegated authority path. The decision is not whether a vendor lists an integration; it is whether the agent can perform the smallest useful task without receiving unrelated data or powers, and whether the organization can explain and revoke that authority later.

This guide introduces a reusable Connector Capability Manifest (CCM), a decision matrix, an action flow, a JSON policy example, and an acceptance-test protocol. It helps a product owner and a security reviewer decide what to expose to an agent before a pilot connects to production systems.

The decision this guide resolves

The reader is choosing how an agent should interact with existing software. The common options—native connector, API integration, browser automation, or no integration—have different failure modes. The correct design depends on the task, the data, the reversibility of actions, identity model, and the review capacity of the team.

Use a connector only when all of these are explicit:

1. The agent has a named business purpose and a bounded workflow.
2. Each tool action has an owner, target resource, and permitted operation.
3. The system can enforce user or service identity, scope, and duration outside the model prompt.
4. The audit record shows what the agent requested, what policy allowed, what the connected system did, and whether a human approved it.
5. There is a tested way to stop the agent, revoke access, and recover from an incorrect write.

If any condition is missing, start with a sandbox, a read-only connection, or a manual export. Do not treat “the agent needs access to the CRM” as a permission specification. That sentence grants too much ambiguity to the model, connector, administrator, and future workflow.

What search results already cover—and the evidence gap

The targeted Search Console view for AI-Due covered 2026-10-14 through 2026-10-21. The query “agent ia connecté aux logiciels” appeared with 5 impressions and average position 18 for the page about platform connectors and APIs. This is a small, local search observation, not a demand estimate or a promise of movement. A related one-impression query asked which agents can integrate with existing data systems. The original site page explains connector categories, an agent architecture, APIs, logs, and human controls. This article uses that baseline but narrows the decision to authorization boundaries for each tool call.

The visible results and product documentation commonly explain connector catalogs, API availability, CRM or support integration, workflow orchestration, and business use cases. Vendor materials can show that a connector exists, but they do not establish that an organization has configured it safely or that a particular action is appropriate. General AI risk guidance explains governance and least privilege, but it does not give an operator a field-level manifest that joins a business task to a connected action, scope, approval, and rollback.

The unresolved operational question is therefore: when should an agent’s request to a connected system be allowed automatically, when should it require a human, and when should it be impossible? The CCM below makes that decision visible and testable.

The source article is AI-Due’s guide to agent platforms, connectors, APIs, and business systems. It introduces the platform architecture; the artifact here adds an action-by-action permission contract.

Facts, inference, and recommendation

Sourced fact — minimize authorization scope. Google’s OAuth policies state that applications should request only the smallest scopes necessary for functionality the user knowingly chose, and explain how to handle granular permissions and denied scopes. Its authorization guidance recommends requesting access when it is needed and disabling features whose required scope was not granted. These are rules and recommendations for Google’s OAuth ecosystem, not a universal API standard, but they illustrate an important implementation pattern: permission is specific, may be partial, and must be checked in the code rather than assumed. See Google’s OAuth 2.0 policies and incremental authorization guidance.

Sourced fact — least privilege and separation. CISA guidance for ransomware defense calls for least privilege and separation of duties, including for third parties, and recommends restricting service control policies from actions such as deleting logs or changing configurations. CISA also discusses time-based privileged access and auditing in its cloud security guidance. The cited material is cybersecurity guidance for organizations, not a bespoke AI-agent connector spec. See the CISA ransomware guide and CISA cloud security technical reference architecture.

Sourced fact — agent scope and human review. KPMG’s July 2025 agentic-AI governance paper recommends defining limits on data access, tool usage, and decision authority; escalating ambiguity; identifying where human approval is required; and maintaining logs and a fail-safe. It is a consulting firm’s proposed control framework, not an independent test of connector products. See KPMG’s AI governance paper for the agentic era.

Inference. A connector catalog says what can technically be called. It does not by itself prove that the current user authorized a specific action, that the agent has the right record, or that the action is recoverable. A broad OAuth scope, a service account shared across agents, and a prompt saying “only update relevant cases” all leave enforcement outside the model’s control.

Recommendation. Express every connected operation as a capability with a business purpose, resource boundary, permitted verbs, data boundary, execution identity, expiry, approval rule, and compensating action. Enforce it in a policy layer between the agent and the connector. The model may propose an operation; it should not mint its own authority.

The Connector Capability Manifest

The CCM is a small, versioned contract for one workflow and one agent identity. It is not a vendor integration checklist. It gives security and operations a common object to review and lets software evaluate each proposed tool call before the call reaches the target system.

Manifest field	What it answers	Example	Failure-safe default
workflow_id	Which approved business process is this for?	support-case-summary	No workflow, no call
agent_id	Which non-human identity is acting?	agent:support-triage:v4	Unknown identity is denied
human_subject	On whose behalf, if anyone, is this call made?	user:rep-42	Do not substitute a shared admin
connector_id	Which target and environment?	crm:sandbox	Production target needs explicit approval
resource_filter	Which records can be accessed?	Cases assigned to team 7	No wildcard tenant access
operations	Which verbs are permitted?	read, draft_comment	Start with read-only
field_allowlist	Which fields may leave the system?	status, subject, public_notes	Deny unspecified fields
purpose	Why is this access needed?	Summarize an assigned open case	Unclear purpose is denied
expires_at	When does this grant stop?	End of pilot session	No indefinite pilot token
approval	Which actions need a person?	Human approves status change	Unknown action requires review
audit_ref	Where is the immutable decision record?	Event ID in policy ledger	No audit reference, no write
rollback	How is an allowed write reversed?	Reopen prior status and log correction	Irreversible action is withheld

This shape is intentionally more specific than a single “read/write” checkbox. read from one team’s assigned cases is different from read across every customer. write to a draft field is different from sending an email, changing a contract, or deleting a record. A useful policy names the business operation and target object, then grants the minimum technical scope that implements it.

Access, authority, and identity are separate

An access token proves that a connected system will accept a credential under its scopes. It is not proof that the current model request is within the organization’s task policy. The authorization service should evaluate both the connector token and the workflow manifest. Where possible, use delegated user identity so normal user access rules still apply. If the connector requires a service identity, isolate it per workflow and restrict it to the records and operations that workflow needs.

The manifest must also distinguish the human who initiated a task from the agent that executes it. If a support rep asks the agent to summarize a case, the audit record should identify the rep, agent version, case, connector, and policy decision. If a scheduled agent runs without a human present, record the accountable owner and trigger. Do not attribute an automated change to a human who never saw it.

Decision matrix: choose the smallest useful capability

Proposed operation	Typical impact	Default mode	Required control before production
Read a small, assigned record set	Confidentiality and scope risk	Automatic only within a narrow filter	Identity check, field allowlist, access log
Search internal documentation	Data leakage and prompt-injection risk	Read-only with source isolation	Retrieval boundary, citation/source reference, data classification
Draft a CRM note without saving	Low impact, still may expose data	Allow in session	Show source fields; user edits before save
Save a draft note	Persistent but usually reversible	Human confirmation or low-risk policy	Diff preview, actor, record ID, correction path
Change ownership or status	Operational routing impact	Approval for initial deployment	Policy check, visible proposed diff, named approver
Send a customer message	External and reputational impact	Human approval	Recipient, content, purpose, channel and policy checks
Change permissions, billing, or contract data	High consequence	Separate privileged workflow	Strong authentication, separation of duties, explicit approval and rollback plan
Delete data, users, logs, or audit controls	Destructive or evidence-destroying	Deny to general-purpose agents	Dedicated break-glass procedure outside the agent

The categories are a starting point, not a universal risk score. A draft note can still be sensitive if it contains health, financial, employment, or legal information. A harmless-looking status change can trigger downstream customer communications. Evaluate the full chain of effects, not only the API endpoint’s verb.

Policy flow: the model proposes, the gateway authorizes

flowchart TD
  A[Agent proposes tool call] --> B[Normalize action and target]
  B --> C{Known workflow and agent version?}
  C -- No --> X[Deny and log reason]
  C -- Yes --> D{Manifest allows verb, record, and fields?}
  D -- No --> X
  D -- Yes --> E{Token scope and user context valid?}
  E -- No --> X
  E -- Yes --> F{Action reversible and low impact?}
  F -- Yes --> G[Execute through connector gateway]
  F -- No --> H{Required human approval recorded?}
  H -- No --> I[Hold for approval]
  H -- Yes --> G
  G --> J[Record result, target response, and audit reference]
  J --> K{Unexpected result or policy anomaly?}
  K -- Yes --> L[Stop workflow, revoke or expire grant, notify owner]
  K -- No --> M[Return bounded result to agent]

The gateway is the enforcement point. Instructions in a system prompt are useful for behavior, but they are not a substitute for authorization at the tool boundary. The policy decision should be deterministic enough to explain and test. A denial should identify the failed rule without revealing more sensitive data than the agent needs to continue safely.

A compact manifest and policy evaluator

The example below shows a workflow-specific capability. It is illustrative, not a drop-in security product. Production implementations must validate tokens with the target identity provider, check tenancy and record ownership server-side, handle revocation, and persist audit events in a protected system.

const manifest = {
  workflowId: 'support-case-summary',
  agentId: 'agent:support-triage:v4',
  connectorId: 'crm:sandbox',
  purpose: 'summarize an assigned support case for its human owner',
  operations: ['case.read', 'note.draft'],
  fields: ['caseId', 'subject', 'status', 'publicNotes'],
  resourceFilter: { assignedTeam: 'team-7', status: 'open' },
  expiresAt: '2026-10-23T10:00:00Z',
  approvalRequired: ['case.status.update', 'message.send', 'case.delete']
};

function authorize(call, ctx, now = Date.now()) {
  if (!ctx.identity || ctx.identity.agentId !== manifest.agentId) return { allow: false, reason: 'unknown_agent' };
  if (ctx.workflowId !== manifest.workflowId || ctx.connectorId !== manifest.connectorId) return { allow: false, reason: 'wrong_workflow_or_target' };
  if (Date.parse(manifest.expiresAt) <= now) return { allow: false, reason: 'grant_expired' };
  if (!manifest.operations.includes(call.operation)) return { allow: false, reason: 'operation_not_granted' };
  if ((call.fields || []).some(field => !manifest.fields.includes(field))) return { allow: false, reason: 'field_not_granted' };
  if (!ctx.resourceMatchesManifest) return { allow: false, reason: 'resource_out_of_scope' };
  if (manifest.approvalRequired.includes(call.operation) && !ctx.approvalId) return { allow: false, reason: 'approval_required' };
  if (!ctx.auditEventId) return { allow: false, reason: 'audit_reference_missing' };
  return { allow: true, reason: 'manifest_match', auditEventId: ctx.auditEventId };
}

The evaluator does not trust a model-generated resourceMatchesManifest Boolean in production. It must derive the match by looking up the record and comparing authoritative attributes. Similarly, approvalId must resolve to an unexpired approval for this exact action, target, and content—not merely to any approval event. The snippet keeps those dependencies visible so a reviewer can see what must be supplied by server-side code.

The manifest is versioned and tied to a deployment. When a workflow needs a new operation, update the manifest through the organization’s review process; do not silently widen an existing token because a prompt has changed. Record who approved the version and compare production calls with the version that was reviewed.

Reproducible acceptance protocol

Before connecting an agent to a production system, construct a small test set of tool calls and expected policy outcomes. Use synthetic records or properly authorized data. Record the test date, number of cases, how cases were selected, excluded scenarios, and who adjudicated ambiguous results. Do not call a local test set a benchmark for model capability.

At minimum, test these cases:

Test case	Expected result	What it catches
Allowed read inside the assigned team filter	Permit and log	Basic happy path
Read of a neighboring team’s record	Deny	Cross-tenant or filter bypass
Request for a field outside the allowlist	Deny or redact	Overbroad data response
Attempt to call an unlisted operation	Deny	Tool catalog mistaken for authority
Expired grant or revoked token	Deny	Stale credential reuse
Write request with no approval	Hold or deny	Prompt-level approval assumption
Approval for a different target or operation	Deny	Replayed or mis-scoped approval
Retrieved document contains hostile tool instructions	Treat as data, not policy	Indirect prompt injection
Connector timeout after a write request	Reconcile state before retry	Duplicate side effect
Audit store unavailable	Deny consequential writes	Silent loss of accountability
Agent version differs from manifest version	Deny and alert	Unreviewed deployment drift
Rollback path is unavailable	Withhold irreversible action	Unsafe recovery assumptions

For each case, capture the requested operation, normalized target, effective identity, policy version, decision, reason, connector response, and resulting state. A “pass” means the system did what the policy specified; it does not prove the policy itself is wise or compliant. A reviewer should inspect both the raw event and the UI shown to the user.

Measure local operations, not invented accuracy

If the team wants to quantify performance, define the denominator first. Possible local measurements include: percentage of tool calls with complete audit references; number of out-of-scope requests correctly blocked; share of approval requests with a matching target and action; time needed for a human reviewer to confirm a proposed change; and recovery success after a simulated timeout.

Report the test date, total test cases, selection method, excluded cases, exact policy version, connector version, and adjudication criteria. Do not call the result “agent accuracy” if it only measures policy enforcement. Do not publish a percentage from a handful of hand-picked examples as a general property of agent connectors. A local test is valuable because it finds a bug in this workflow, not because it predicts every other organization’s outcome.

Implementation sequence for a controlled pilot

1. Map the task before selecting a connector

Describe the current workflow from trigger to completion. List the people, systems, records, decisions, exceptions, and external side effects. Identify where the agent would read, draft, recommend, save, send, or delete. If no one can explain the manual process, do not automate it yet; a connector will make an unclear process faster, not clearer.

Define a narrow first task with a measurable completion condition. “Improve customer support” is not narrow. “Summarize the assigned open case and draft a note for the case owner to review” is bounded. The second task can be evaluated without giving the agent permission to close cases or message customers.

2. Inventory the data and boundaries

Classify the fields the agent needs. Separate data needed for the task from data that happens to be available through the API. Check whether retrieved documents or CRM text can contain user-controlled instructions. Treat connected data as untrusted content; it may inform the answer but should not rewrite the policy or authorize another tool.

Map tenancy, team, record ownership, data residency, retention, and logging. A connector that can query all customer records may still be technically convenient, but if the first workflow needs only one assigned case, that broad reach increases impact without adding task value. Restrict access at the connector, API gateway, or service identity—not only through a filtered prompt.

3. Choose identity and permission mechanics

Prefer a user-delegated identity when the target platform supports it and the user’s existing permissions are appropriate. This preserves an important accountability link, but it can create consent, token-lifecycle, and user-experience issues. Google’s documentation, for example, recommends incremental authorization for its OAuth flows and requires applications to check which scopes were actually granted. That is a platform-specific implementation model worth learning from, not a promise that all connectors behave identically.

If a service account is required, create a distinct identity for the workflow or agent class, define a named owner, and avoid sharing administrator credentials. Use the narrowest role the target system supports. Where the platform only offers broad scopes, add a policy gateway that enforces record and field boundaries before the request leaves the agent service. Do not rely on an audit log after an overbroad call as the only control.

4. Make approval meaningful

An approval should show the action, target, relevant fields, and expected consequence. “Approve agent access” is not equivalent to “approve changing case 123 from pending to resolved.” The reviewer should be able to reject, edit, or defer. Record the approver and approval context. Expire approvals when the content changes materially or the target changes.

For low-impact reads, approval for every API call may slow work without improving decisions. Instead, define a pre-approved read boundary and monitor it. For high-impact writes, human confirmation may be needed even if the user asked the agent to “handle it.” The right dividing line depends on reversibility, impact, data sensitivity, and the cost of a mistaken action.

5. Run shadow mode before writes

In shadow mode, the agent proposes tool calls and summaries but the gateway does not execute consequential changes. Compare the proposed action with what an operator would do. Review false positives, missing context, prompt-injection attempts, and records that fall outside the manifest. Shadow mode is an operational recommendation; it is not a guarantee that production behavior will match the sample.

After the review, permit only the lowest-risk action that unlocks actual value. For example, let the agent retrieve assigned case fields and draft a note, but require the rep to save it. Track whether the draft helps or creates rework. If it is not useful, stop rather than widening access to justify the integration investment.

6. Deploy with a stop path

Set a person and channel responsible for disabling the workflow. The stop path should be separate from the agent’s own permissions. Revoke its token or disable the integration at the policy gateway. Define what happens to in-flight work, queued actions, and partial writes. A kill switch that leaves an automation queue running is not a complete stop mechanism.

Establish alerts for denied calls, repeated retries, unexpected records, scope changes, missing audit events, and unusual write patterns. During a pilot, make ownership and escalation obvious. If the team cannot distinguish a model error from an identity or connector failure, the runbook is not ready.

Important disagreements and where the recommendation fails

There is a tradeoff between friction and control. Asking for approval before every read can make an agent unusable and train people to click through prompts. Broad service accounts can make deployment quick but weaken attribution and enlarge the blast radius. The balanced design is not “human approval everywhere” or “full autonomy”; it is pre-approved, narrow capabilities for low-impact actions and explicit review for actions with meaningful external consequences.

OAuth documentation shows that consent may be granular and that some scopes can be denied; application code should not assume that every requested permission was granted. This is useful evidence for designing partial-access behavior, but Google’s policy does not dictate how every enterprise API connector must work. Some systems provide coarse scopes. If the connector cannot express a narrow grant, use a gateway or select a different integration path.

CISA guidance is written for cybersecurity and government cloud contexts. Its least-privilege and separation-of-duties principles support access boundaries, but they do not tell a product owner which CRM field the agent should read. KPMG’s framework is a consulting recommendation and can help structure oversight questions, but it is not a neutral validation of a specific product or workflow. The CCM is an original operational synthesis, not an adopted standard.

The design also fails if the underlying human roles are ambiguous, source data is stale, connector logs omit the effective identity, or a downstream automation changes the impact of a seemingly small write. A case status update may trigger a customer email; a document summary may expose restricted data in a broader channel. Trace downstream consequences before classifying an operation as “low risk.”

Failure modes and guardrails

The connector token becomes a blanket credential

A single service account gives an agent broad access to several systems. Split identities by workflow, environment, and purpose where practical. Remove unused scopes. Monitor token creation and rotation. If a platform cannot separate permissions enough, add an enforcement gateway or keep that connector out of the pilot.

The prompt is the only authorization check

The system prompt says “never modify a case unless asked,” but the tool can call any update endpoint. A retrieved document or user message can then manipulate the model’s next action. Enforce allowed operations in code at the tool boundary. Treat model instructions and source data as inputs, not as the policy engine.

An approval is replayed for a different action

The user approves a note draft, then a retry sends a customer message using the same approval ID. Bind approval to agent, version, operation, target record, payload hash or change summary, and expiry. Require a new approval when the material action changes.

Retries duplicate a side effect

A timeout occurs after the CRM accepted a write but before the agent receives the result. Blind retry can create duplicate notes or messages. Use idempotency keys where supported, query the target state before retry, and preserve a reconciliation record. If you cannot determine whether a side effect happened, hold for a human.

The agent can modify its own controls

An agent is given permission to create users, grant scopes, edit logs, or change the policy gateway. Keep administrative controls outside its capability manifest. Separate duties so the system cannot both perform a business action and erase evidence of that action.

A “read-only” connector still leaks data

Read-only prevents writes; it does not prevent overcollection, cross-tenant access, prompt injection, or disclosure in a generated answer. Restrict the records and fields returned. Apply data-loss controls to the agent’s output and ensure the user receiving the answer is authorized to see it.

Logs exist but cannot answer the incident question

The platform records “tool called” without recording which human initiated the workflow, which agent version ran, which policy applied, or which target was changed. Keep enough metadata to reconstruct decisions, while avoiding unnecessary copies of sensitive content. Test an incident reconstruction exercise before launch.

The kill switch is only a dashboard button

The visible control stops new prompts but leaves existing credentials and queued jobs alive. Define the independent revocation steps, the order in which they occur, and how the team confirms that all paths are disabled. Practice both routine shutdown and urgent revocation.

Validation checklist

• [ ] The workflow is a bounded task with a named business owner and accountable technical owner.
• [ ] Agent identity and human initiator are both recorded.
• [ ] Connector, environment, record filter, field allowlist, and allowed operations are explicit.
• [ ] Unknown or unlisted actions are denied by code, not only discouraged by prompt.
• [ ] Production access is separate from sandbox access.
• [ ] Tokens and approvals expire; revocation has been tested.
• [ ] High-impact writes have a target-specific human approval or an equivalent approved control.
• [ ] Retries are idempotent or reconciled before another side effect is attempted.
• [ ] Logs include the manifest version, decision reason, target, result, and actor context.
• [ ] Retrieved content cannot change tool permissions or policy.
• [ ] A person independent of the agent can stop the workflow and revoke access.
• [ ] Rollback or compensation exists for every write the pilot can perform.
• [ ] Acceptance tests cover denied scope, wrong target, expiry, prompt injection, timeout, and log outage.
• [ ] Data retention, output sharing, and deletion paths are documented and tested.

Method and limitations

This review was conducted on 2026-10-23. The GSC view covered 2026-10-14 through 2026-10-21 for the AI-Due property and used query-plus-page dimensions. The query “agent ia connecté aux logiciels” had 5 impressions, no clicks, and average position 18 for the connector-platform page in that view. The adjacent question query had one impression. These are the observed rows, not a representative sample of organizations or search demand.

The source review included the original AI-Due connector overview, current Google OAuth policy and authorization guidance, CISA cybersecurity guidance, and KPMG’s July 2025 agentic-AI governance paper. CISA sources are organization-level security guidance; Google’s policy applies to Google APIs; KPMG’s framework is advisory material. None is a test of the CCM or a comparison of connector vendors. Vendor capability claims were not treated as independent evidence of safety.

The manifest, decision matrix, policy flow, code, and test protocol are original design assets. They were not deployed or evaluated against a production CRM. No error rate, time saving, incident reduction, adoption level, or conversion improvement is claimed. A real implementation must adapt the fields to its identity provider, connector semantics, data classification, and jurisdiction. The code omits cryptographic token validation, record lookup, durable audit storage, concurrency control, and rollback integration; these omissions are deliberate boundaries, not optional production work.

The practical rule

Treat every connector as a delegated capability, not a checkbox. Give the agent the minimum resource and operation that completes the named task, preserve identity and audit context, and separate proposal from authorization. If the task cannot be bounded, the permission cannot be enforced, or the action cannot be recovered, keep the agent in read-only or sandbox mode until those gaps are fixed.