--- isPublished: true template: "page.peb" title: "AI & Agent Governance" displayName: "AI & Agent Governance" description: "How iDialogue composes agents, bounds authority, uses provider controls, records transcripts, and meters agent work." category: "trust" contentType: "overview" audience: "admin" tags: "trust,ai,agents,governance,openai,approvals,transcripts,credits" section: "trust" seoTitle: "iDialogue AI and Agent Governance" seoDescription: "Review iDialogue agent composition, authority, approvals, OpenAI data controls, transcripts, audit records, and usage controls." ---

Trust Center ยท AI & Agent Governance

Govern the agent, not just the model

AI governance extends beyond the model. iDialogue combines instructions, approved data, tools, Connections, permissions, workflow controls, and human review to define what each agent can access and what it is allowed to do.

Layers of agent control

An iDialogue agent operates within several configurable layers: - **Instructions** that define its purpose and boundaries; - **Salesforce context** selected for the workflow; - **Knowledge and memory** approved for the use case; - **Skills and tools** enabled for the current execution context; - **Connections** that determine access to Salesforce and external services; - **AI models and processing providers** selected for the workflow; - **Human review and approval requirements** surrounding consequential actions; and - **Transcript, usage, and audit records** that provide operational visibility. Administrators configure these controls for the specific agent and workflow rather than granting every agent the same capabilities.

Authority and approvals

Agents do not receive unrestricted authority. What an agent can do is constrained by the data supplied to it, enabled skills and tools, Connection permissions, workflow configuration, and any required approval steps. The following diagram illustrates the governance pattern for actions that may create or change business data: ~~~mermaid flowchart TD Start["User or background event starts an agent"] --> Context["Resolve record, file, tenant, and run context"] Context --> Tools["Offer only tools permitted for that run context"] Tools --> Scope["Apply object, field, operation, and instruction boundaries"] Scope --> Consequence{"Does the action require review?"} Consequence -->|"Yes"| Confirm["Show the proposed action and request confirmation"] Consequence -->|"No, explicitly authorized"| Execute["Execute within configured authority"] Confirm -->|"Approved"| Execute Confirm -->|"Rejected"| Stop["Stop without the side effect"] Execute --> Audit["Record configured transcript, tool, and credit evidence"] Audit --> Result["Return the result to Salesforce or the user"] ~~~ An agent's effective authority is constrained by: 1. the data and context supplied to the run; 2. active skills and tools; 3. the Salesforce or external Connection identity; 4. object, field, record, endpoint, and operation access available to that Connection; 5. workflow-specific approval requirements; and 6. downstream sharing or publication configuration. Server-side Salesforce actions are primarily bounded by the configured Salesforce Connection or integration identity. External workflows should not be assumed to automatically reproduce all row-level sharing and field-level security of the initiating Salesforce user. The current Salesforce data-manipulation tool supports insert, update, and upsert operations. Delete is not supported.

Human review and approval

iDialogue workflows can require human review before consequential actions are completed. Review is particularly relevant for: - extracted names, dates, amounts, requirements, and compliance obligations; - new or updated Salesforce records; - commercial commitments and customer-facing claims; - generated proposals, agreements, quote explanations, and handoff documents; - external messages, invitations, Rooms, or public pages; and - actions that consume material credits or invoke paid Connections. Approval requirements are configurable by workflow. Administrators can design agents to propose an action for review, require explicit confirmation, or execute pre-authorized actions automatically.

Interactive and background agents

iDialogue agents can run interactively from Salesforce, operate on files, or execute automatically in response to configured events. Each execution mode can expose a different set of approved skills and tools based on its run context. Background agents require additional governance because they can continue working after an interactive request has completed. Administrators should review the initiating event, permitted data, available actions, retry behavior, usage budget, destination for results, and exception-handling path.

OpenAI Integration

iDialogue supports OpenAI for selected language, image, file, and agent workflows. Organizations can use an iDialogue-managed provider account or, for approved deployments, their own OpenAI API key. A customer-provided key places provider-level administration within the customer's OpenAI organization, including provider usage visibility, billing, rate limits, and applicable account settings. Provider credentials are one layer of governance. They do not by themselves determine: - which Salesforce data or other context iDialogue sends; - whether a request uses store=true or store=false; - what iDialogue stores in transcripts, artifacts, memory, logs, or billing records; - whether optional provider sharing settings are enabled; or - how other processing providers are configured. Read the [OpenAI Connection guide](/connections/openai.html) and [OpenAI Data Processing Addendum summary](/trust/compliance/openai-data-processing-addendum.html).

Provider data controls

### Model training OpenAI states that API data is not used to train its models unless the API customer opts in. Optional feedback, evaluation, fine-tuning, and service-improvement sharing programs are separate settings that should be reviewed for the applicable provider organization and project. ### Application state Some iDialogue workflows use OpenAI's stored Responses functionality to support threaded conversations, background continuation, and file-processing workflows. Current reviewed iDialogue Responses API paths use store=true where this functionality is required. ### Retention OpenAI's current official documentation states that stored Responses application state is retained for at least 30 days. Responses application state, abuse-monitoring logs, uploaded files, conversation objects, and optional sharing programs are separate data classes and may have different controls or retention behavior. Endpoint features, provider-approved controls, and contract terms can affect the applicable behavior. For current endpoint-specific details, see OpenAI's official [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data#default-usage-policies-by-endpoint). Zero Data Retention is a provider-approved configuration with endpoint and feature limitations and should be evaluated for the specific deployment.
OpenAI platform Data controls page showing audit logging active and API call logging enabled per call for the iDialogue organization on August 10, 2026.
OpenAI organization data-control settings captured August 10, 2026. Endpoint-specific storage and retention behavior is documented separately above.

Transcripts and audit

Threaded agent workflows can maintain an activity record containing: - user and assistant messages; - model and response identifiers; - tool names, arguments, and returned details; - token usage and processing metadata; and - credit consumption and billing events. These records support conversation continuity, troubleshooting, governance review, usage reconciliation, and investigation. Because transcripts and tool records may contain business-sensitive information, they should be treated as a distinct data class with their own access and retention considerations. Operational and security logs are separate records and may contain different information.

Usage and execution controls

iDialogue meters agent, model, file-processing, and workflow activity using credits. Usage records support customer visibility, billing, investigation, and capacity planning. Provider rate limits remain subject to the provider account, selected model, and current service conditions. For approved deployments, customers may use their own provider credentials so provider billing, account administration, and rate limits remain within their governance boundary. Recommended controls include: - enable only the agents, skills, Connections, and background triggers required for the workflow; - establish budgets and internal escalation thresholds; - test retry and failure behavior to reduce unintended duplicate work; - monitor iDialogue credit and provider-account usage; - separate experimentation from production credentials; and - establish an owner for overage, capacity, and rate-limit decisions.

Governed workflow examples

Two common Salesforce workflows illustrate how agent governance applies in practice: ### Understand a file A user can provide a business card, RFP, agreement, image, or other file. An approved workflow can perform OCR, extract structured information, summarize content, answer questions, or propose Salesforce updates and next actions. Controls determine which file and Salesforce context are processed, which provider receives the required information, what Salesforce data may be created or updated, whether human review is required, and what file, knowledge, and transcript information is retained. ### Generate a reviewed document Salesforce context and an approved template can produce a proposal, agreement, quote explanation, handoff document, or other customer-facing artifact. Controls determine which Salesforce fields are supplied, whether content is produced through a deterministic merge or AI-assisted workflow, where human review occurs, how the resulting artifact is stored, and where it may ultimately be delivered or shared. These examples illustrate common governance patterns rather than establishing one permission or retention model for every iDialogue feature. Use the [Security & Data Handling](/trust/security-data-handling.html#file-and-agent-data-flow) page to trace the data flow for a specific deployment.

Review an agent before production

We can walk through a proposed agent's Salesforce access, data inputs, enabled tools, AI providers, approval requirements, storage, and audit trail before deployment. Contact support@idialogue.app.