Connect Copilot Studio to VeriProof

Start with the Copilot Studio quickstart to choose a connection and run the first checks. Use this guide for implementation, deployment, and recovery.

Choose the path that matches the work:

Connect the VeriProof MCP server directly through Copilot Studio’s MCP onboarding wizard. This connection needs no customer-hosted Azure Function, custom connector, or managed solution. Protected business writes remain a separate connection because the customer system must own the current facts and recorded result.

The native VeriProof Policy workspace remains the policy authority. Copilot Studio policy drafting cannot activate, enforce, approve, delete, create Developer requests, change organization rules, or ingest evidence.

Send application evidence through a VeriProof SDK or supported ingest endpoint, not through MCP.

Prepare a policy draft

Policy drafting is available only to a signed-in policy author with access to the selected application. It uses these tools:

• get_policy_authoring_context starts with the application. It returns a compact summary of both supported rule contexts and explains when to use each one. After a context is selected, it returns the data the rule may use, whether each field is confirmed, and where it comes from.
• compose_policy_rule_draft accepts business intent and structured examples from Copilot’s model. VeriProof checks the selected facts, compiles the rule deterministically, and returns the draft and test results.
• validate_rule_draft checks the logic and rejects application data that is not confirmed for policy use.
• test_rule_draft runs deterministic policy tests and returns each case result.
• assess_rule_impact compares a saved activity rule with recent application activity when that comparison is available.
• save_rule_draft saves the confirmed draft once, even if Copilot retries, and returns its portal review link.

The Copilot Studio customer bundle includes policy-authoring/agent-instructions.md. Add that copy-ready text to a dedicated policy assistant, then enable only these six tools.

Standard controls use facts supplied by VeriProof and need no application field setup. For application-specific facts, the tools show the source, confirmation state, and activation blockers.

Developers confirm those facts and mappings. Runtime evaluations then check what the application sends; one observed payload cannot authorize a field.

Policy drafting can identify unavailable data. It cannot invent or confirm that data, or create Developer work.

Start with the application ID and the discover context. VeriProof returns the available contexts, then the author selects Recorded application activity or Governed action for the draft. Copilot uses the returned fact keys to build the typed proposal. The user does not need to construct profile identifiers, contract versions, or Rego paths.

Before you start

Confirm these items before you configure the agent:

• Author access: Assign Microsoft 365 Copilot or a Copilot Studio User License to the agent author. A trial license can test an agent but cannot publish it.
• Environment capacity: Give the selected environment prepaid Copilot Credits, access to the tenant capacity pool, or pay-as-you-go billing. Set a spending limit and alerts.
• Publishing access: Add the author to the Copilot Studio authors security group. Confirm that the tenant allows publishing agents with AI features.
• Supported channel: Use Teams, a custom website, Omnichannel, SharePoint, or another channel that supports signed-in tools. The demo website does not support user-authenticated tools.
• Data policy: Permit the VeriProof MCP connection. Keep every connector used by the same action in compatible Power Platform data groups.
• VeriProof access: Give each user access to the applications and records the agent may use.
• MCP address: Copy the public HTTPS address from More tools → Agent tools → Connect in VeriProof.

See Microsoft’s current billing and publishing requirements , user-authenticated channel support , and Power Platform data-policy rules .

The portal must show Ready to connect. A localhost or private address is for local testing and cannot be reached by Copilot Studio. Direct MCP access needs no customer-hosted compute, custom connector, or managed solution.

Copilot Studio uses the agent’s model to prepare the versioned intent proposal and examples. VeriProof does not call a second model for this path. The native Policy workspace can use the customer-configured provider for its own assisted authoring experience.

A protected business action also requires Developer access to the system that owns the record or operation, a VeriProof application, and a VeriProof SDK.

Connect the VeriProof MCP server

Use this connection when the agent needs to find or explain VeriProof records.

1. In Copilot Studio, open your agent and select Add tool.
2. Choose Model Context Protocol, then add an existing MCP server.
3. Enter the MCP address shown in the VeriProof customer portal.
4. Choose OAuth 2.0, then choose Dynamic discovery.
5. Use User authentication. Save the tool and sign in to VeriProof when Copilot Studio asks. Each person keeps the same tenant, application, role, and audit access they have in VeriProof.
6. Ask the agent, “Which VeriProof applications can I access?” Confirm that the answer matches the customer portal.

The MCP server can find evidence and complete work that VeriProof already exposes to the signed-in user. It does not control unrelated Copilot tools or actions in another system. See the VeriProof MCP server guide for its supported tools and connection details.

Add a protected business action

Prefer the API that already owns the business action. Add the VeriProof registered-action adapter to that API, then expose the bounded action to Copilot Studio through a REST API tool, custom connector, or agent flow. This keeps the rules check, current-record validation, one-time execution, and target receipt at the write boundary without adding another hosted service.

Start with one action. Industry-neutral examples include changing a record state, releasing a queued operation, or sending a confirmed notice.

Use a managed agent flow when existing Power Platform connections can run the same deterministic sequence with the required user identity.

Microsoft documents restrictions on user-credential flows in customer-managed-key environments. If the required identity path is unavailable, use the action-owning API; do not substitute maker credentials. Do not expose a second tool that performs the same write. A flow proves control of the configured agent path. It proves execution-boundary enforcement only when the target API also verifies the exact authorization, record version, idempotency key, and receipt contract.

Build the agent flow

Create the flow in Copilot Studio when existing Power Platform connections can perform the required read and write:

1. Start with When an agent calls the flow and finish with Respond to the agent.
2. Turn off asynchronous response and keep the normal path under the 100-second action limit. Confirm that the environment supports user-authenticated flow connections.
3. Read the current record and reject an ambiguous or changed version.
4. Ask VeriProof to evaluate the registered action and current facts.
5. Stop without a write for Deny, Warn, or review-required results.
6. Execute an allowed action once through one target connection.
7. Record the target receipt and new record version with VeriProof.
8. Return only the registered customer result fields.

Import the connector-only solution first. Then import the dependent solution and select the connection. It includes Review governed record update, Submit governed record update, and an industry-neutral reference agent. The reference topic uses Copilot’s model to interpret intent and present returned facts. VeriProof and the customer action owner remain the decision and execution authorities. Customers can use the reference agent or add both flows to an existing agent. See Microsoft’s agent flow requirements  and solution import order .

The optional Azure action-owner reference is for customers that cannot change an existing action-owning API and need stronger isolation than an agent flow provides. It is not part of MCP setup.

The maintained loan example shows this pattern:

1. Copilot Studio asks the action-owning service for the current loan details.
2. The agent shows only the applicant, loan reference, amount, credit score, LTV, DTI, risk, and current status.
3. The agent asks for the exact named command Run [name]‘s decision. Viewing the application does not submit a business action.
4. The action-owning service checks the current user and loan again.
5. The service sends the lending application’s proposed decision and current business facts to VeriProof.
6. VeriProof returns the permitted result.
7. The action-owning service records an allowed result once and returns a link to the evidence.

The agent never writes or changes the business rules. The conversation does not supply the final loan facts, user access, application scope, or recorded result.

When the user asks for the prepared application list, show only stable names and loan references. Load the selected record before showing its current amount or status. This prevents the model from inventing data that belongs to the action-owning service.

Add the adapter to the action owner

Use the sample in sdk/examples/loan-approval-simulator/connector as the starting point. It includes:

• A Microsoft Entra sign-in check for the Copilot user.
• A current-record lookup from the business system.
• A named, record-bound confirmation that can be submitted once.
• A VeriProof TypeScript SDK call before the loan record changes.
• Clear handling for allowed, stopped, changed, and review-required results.
• An evidence link and exact cleanup for sample records.

Replace the sample loan store with your business system. Keep the same ownership rule: Copilot Studio must not receive another tool that can perform the same write without the registered-action boundary.

The release bundle keeps this example in references/VeriproofCopilotLoanReference.zip. The reference contains synthetic records, its own agent instructions, a connector generated from [email protected], helper source, focused tests, cleanup, and a manifest naming what customers replace. The universal agent does not contain lending instructions. The service implements the generated /api/governed-actions/loan_decision contract and requires the exact delegated Loan.Decide permission. An application role cannot replace that user permission. It is an external lending example, not VeriProof core processing or production lending guidance.

Add the custom connector

1. Register the action-owning API in Microsoft Entra and expose a delegated permission for the business action.
2. Import the custom connector before any flow or agent action that uses it.
3. Create the connection as the signed-in business user.
4. Add the read action and the record action to the agent.
5. Remove any direct connector or HTTP action that can make the same business change.
6. Keep credentials in the connector connection or your secret store. Do not place them in agent instructions or flow variables.

Keep permission prompts out of the task

Copilot Studio asks each person to authorize a tool that uses their credentials. It asks again when the connection expires or is revoked. This is a Microsoft security boundary, not a VeriProof dialog.

Connect the tool when the person starts using the agent, before they begin a business action. Reuse one connector connection for its read and write actions so the person does not create separate connections during the task. Require one explicit, record-bound confirmation before a record can change. This can be a named command or an Adaptive Card action.

The maintained synthetic loan demo uses Maker authentication only for Get current loan details. That tool reads public sample data and cannot submit a decision. Submit a loan decision request keeps User authentication because it performs an action for the signed-in person. Approve both tool permissions during the pre-demo check; Copilot Studio then carries those permissions into a new conversation until the connection expires or is revoked.

Do not switch a protected business action to maker-provided credentials to remove the prompt. That would run the action with the maker’s access instead of the signed-in person’s access. Maker-provided credentials are suitable only for low-risk shared information that does not depend on the person’s VeriProof role or application access.

See Microsoft’s guidance for tool authentication  and connector credentials .

Record the deployment in VeriProof

Before installation, verify the package with Test-VeriproofCopilotStudioReleaseBundle.ps1 and a release certificate obtained through an approved VeriProof channel. Do not use the certificate inside the package as its own trust source. The portal rejects development manifests but does not verify the cryptographic signature.

Before registration or installation, an Administrator or Developer can open Agent tools > Agent portfolio and select Check Copilot Studio package. Select the package manifest, its prerequisites report, and the matching Power Platform environment. The check shows blocking work and Administrator reviews without installing the package, registering an agent, or granting access.

An Administrator or Developer with application access records the deployment once. In Agent tools, open Agent portfolio, select the registered agent, and choose Record Copilot Studio deployment.

1. Choose release-manifest.json from the expanded signed package using Select release manifest.
2. Select the prerequisites report created from the same expanded package and settings file.
3. Paste the Power Platform environment ID or its environment URL.
4. Resolve every Action required result. If the report contains Could not verify, an Administrator must review and confirm those checks.
5. Confirm the readable deployment name and select Record deployment.

VeriProof reads the package, action, version, source commit, and action class from the manifest. It accepts only a prerequisites report with the same package, registered action, settings digest, and Power Platform environment. You do not enter those technical values by hand. Package details remain available in the expanded review section. The binding records identity and qualification scope; it does not grant the agent access or authorize a business action.

Run the stopped and completed action checks after you record the deployment. Earlier sessions belong to the previous setup and do not qualify this package.

The registered agent shows three application-specific milestones: Deployment recorded, First governed action, and Production qualified. VeriProof derives the last two from package-bound evidence created after the recorded deployment. The panel names the next missing result or qualification step. It does not infer connection or production status from browser activity.

Download qualification files

After recording the deployment, an Administrator, Compliance Officer, or authorized Auditor can select Download qualification files. The signed record shows any verified stopped or completed action and names the qualification checks that remain open. VeriProof returns one ZIP file with:

• qualification.json, the signed application and package record.
• veriproof-evidence-public-key.pem, the public key used to verify that record.
• README.txt, the verification instructions.

Keep the JSON and public key together. Run the checker from the expanded VeriProof package:

.\Get-VeriproofCopilotStudioInstallationState.ps1 `
  -QualificationEvidencePath .\qualification.json `
  -TrustedQualificationPublicKeyPath .\veriproof-evidence-public-key.pem

The checker rejects changed content, a different public key, stale package details, or a different registered action. Developers can record the deployment but cannot download qualification evidence.

The reference package includes Update-VeriproofGovernedLoanConnector.ps1. The command rotates the connector application’s Microsoft Entra credential and supplies its value to Power Platform through a temporary file. It removes the file after the update and removes an unused credential if Power Platform rejects the connector.

Ask each user to create a new connection after rotating the connector credential. A saved connection cannot use the replacement credential until that user signs in again.

For the loan example, add these actions:

• Get current loan details
• Submit a loan decision request

Keep the user and action owner separate

The integration uses two identities for different jobs:

The action-owning service must verify the Microsoft user token before it reads a record or submits a decision. It must derive the tenant and application on the server. Do not accept either value from the conversation.

Give the agent clear instructions

Adapt this text to your action and business terms:

Show the current record details before asking for a decision.
Show only the facts the user needs to review.
Require an exact, record-bound confirmation such as Run [name]'s decision.
Do not treat conversational intent as a submitted decision.
Record the decision only after the user confirms the current details.
If the record changed, fetch the current details and ask the user to confirm again.
Show App decision, VeriProof rule check, and Final result in that order.
State clearly whether the proposed change took effect.
Use the policy message returned by VeriProof as the reason. Do not create or rewrite a reason.
Include one Review evidence link when it is available.
Keep implementation and diagnostic details out of the response.

Bind the conversation to its evidence

Record the client and business subject through the SDK’s shared session context. Provide the source, client session ID, subject name, and subject reference. Use the helper for your language:

• TypeScript: withClientContext
• Python and Rust: with_client_context
• .NET and Go: SetClientContext
• Java: setClientContext

In Copilot Studio:

1. In the Conversation Start topic, set a global variable to System.Conversation.Id.
2. Bind every governed tool’s required client_session_id input to that variable.
3. Confirm that the variable contains the runtime conversation value, not the expression as literal text.
4. Stop submission when the value is missing or unresolved. Do not ask the model or user to supply it.

The saved session must contain its conversation reference when it first appears in VeriProof. Derive the signed-in actor from the delegated access token. Never accept an actor identity supplied by the agent.

The session page distinguishes Copilot Studio activity from website and other SDK activity. Every channel stays under the same application and rules.

Use the standard Copilot Studio agent experience when a governed action must retain an exact conversation reference. Microsoft’s new GitHub Copilot agent experience does not provide topics or system-variable binding, and agents cannot move between the two experiences. If an agent cannot supply the runtime conversation value, omit the action until it can. Never replace the value with model-generated text.

The subject reference supplies the compact business-record chip in the session header. The loan example passes LN-5934, so the portal shows that value. This is a shared capability, not lending logic in VeriProof. Other applications can pass an order number, case reference, claim reference, service ticket, or another stable identifier that is safe for authorized users to see. The application sets the value through the SDK client-context helper for each session. Selecting an industry does not select or infer a business record.

Keep the reference short and stable. Do not place a person’s name, email address, access token, secret, or regulated customer data in it. Use the subject name for a readable record label and the subject reference for the business system’s identifier.

Test the complete experience

Use sample records that cover each result your rules can return.

Control test credit use

Use the embedded test chat while you refine instructions. Run connector, flow, MCP, and policy checks directly before you spend credits on the complete agent path. Then run each required result once through the published agent.

For a short qualification run, use pay-as-you-go billing with a small environment limit and alerts. Prepaid capacity expires monthly and does not carry forward. Proactive greetings can consume Copilot Credits. Turning them off does not guarantee zero cost; preparing an agent for a conversation can also be billable. Test the connector, flow, MCP server, and policy response directly before running the complete agent conversation. See Manage Copilot Studio capacity  for current controls.

• Allowed: The business system records the permitted result once. The evidence link opens the matching VeriProof decision.
• Stopped: The business record does not change. The agent shows the plain-language policy reason returned by VeriProof.
• Changed: The business system records only the result returned by VeriProof. The agent states both the requested and recorded results.
• Review required: The business record does not change until the approved review is completed through the supported continuation path.
• Ambiguous request: The agent asks the user to choose the exact record.
• Changed or expired record: The service fetches the current details and asks for confirmation again.
• Repeated submission: The business action runs no more than once.
• Bypass attempt: A request that bypasses the registered-action boundary is rejected.

After each run, compare the business record with its VeriProof session, decision, review, receipt, and evidence link.

Use the sample’s cleanup procedure to remove only records created by that test. Preserve the evidence needed for qualification.

Publish and operate the agent

Publish only after the connection, user access, business results, and evidence links match in your test environment.

• Apply Power Platform data policies to the connector and approved endpoints.
• Keep maker access separate from the account that performs business actions.
• Review connection health after connector or sign-in changes.
• Recheck the full action after changing the agent, flow, registered-action adapter, business rule, or target-system API.

If Copilot Studio reports that its connection list may be out of date, open the agent’s connections, refresh the VeriProof connection, and repeat one read and one business action before publishing.

Move the integration between environments

Package the custom connector separately from the agent or flow that uses it. Move only the parts required for the selected action path:

Before importing a solution, copy deployment-settings.template.json and run Test-VeriproofCopilotStudioPrerequisites.ps1. The check calls the selected registered action’s health address. It stops setup when the host serves another action or does not provide the required route. Resolve each Action required result. An authorized customer administrator must review each Could not verify result for user licensing, environment capacity, publishing access, solution-import permission, Power Platform data policy, and Microsoft Entra tenant consent. The check does not read the connector secret. Direct MCP setup does not use this package check.

1. Deploy the registered-action adapter with the existing action-owning service. Select the optional Azure reference only when no qualifying service exists.
2. Import VeriproofGovernedActionConnectorSolution_managed.zip from the VeriProof bundle. Import it before any solution that contains connection references, flows, or the agent.
3. Set the connector environment variables for its host, OAuth client ID, authorization URL, token URL, and delegated permission. Run the prerequisite check to confirm that the host serves the selected registered action and Microsoft Entra exposes the exact permission. Store the client secret as a Key Vault-backed Secret value. Do not include a secret value in the solution.
4. Save the connector after an environment-variable change. Assign the intended security roles, then create each user connection. Connector role assignments do not move with a solution.
5. Create the governed-action connection.
6. Import VeriproofGovernedActionAgentSolution_managed.zip and select that connection for vp_VeriproofGovernedAction.
7. Confirm that both flows are on. Use the included reference agent or add both flows to an existing customer agent.
8. Apply the environment’s Power Platform data policy and approved endpoint list.
9. Configure the customer agent’s user authentication. Test one stopped action and one recorded action before publishing.

If setup stops during sign-in or import, run Get-VeriproofCopilotStudioInstallationState.ps1 from the expanded bundle. The checker reads Power Platform’s installed solutions, connection state, flow state, and published agents. Continue from the reported step. Download the qualification ZIP from the registered agent in Agent portfolio. Pass qualification.json through -QualificationEvidencePath and the included public key through -TrustedQualificationPublicKeyPath. The checker verifies the signature before it reads the payload. It then accepts only evidence bound to the exact package, registered action, application, and environment. It rejects altered, untrusted, or stale exports and does not infer evidence from browser progress.

The report uses four states:

• Complete: The server returned the required component and state.
• Action required: A known missing or failed item needs work.
• Could not verify: The available server inventory does not prove the result.
• Not applicable: The selected path does not use that step.

An Action required result blocks installation. Could not verify identifies an Administrator check that the package cannot automate, such as licensing, import permission, data policy, or tenant consent. The portal requires explicit confirmation of those checks before it records the deployment.

Proof is cumulative. Connected requires one active governed-action connection, both flows on, and a published active agent. First governed action also requires one allowed action with a protected-system receipt and one stopped action with no protected-system change. Both results need VeriProof evidence links. Production qualified requires a cryptographically verified, current-package record for the selected application, action owner, rules, connections, flows, agent, lifecycle checks, and cleanup.

Before moving from development to test or from test to production, run Compare-VeriproofCopilotStudioPackages.ps1 against the expanded packages. Rebind the target VeriProof application, endpoints, OAuth application, Key Vault reference, connection, roles, data policy, and agent authentication. Prior-environment evidence does not qualify the target environment. Repeat the prerequisite check, confirm both flows, and record one stopped action and one recorded action.

Advanced Connector Policies can allow or block the complete VeriProof MCP server. They do not control individual MCP tools. Use VeriProof permissions for tool access, and use the registered-action boundary for each protected business action.

To roll back, restore the previous agent, connector, flow, and adapter versions that belong to the selected path. Reconnect affected users, then repeat the stopped and recorded action checks. Do not restore a direct action that bypasses the registered-action boundary.

Follow lifecycle-plan.json for install, upgrade, rollback, and removal order. Before upgrade, retain the current signed compatible bundle for rollback. A rollback restores only package-owned components, reapplies target bindings, invalidates later-package qualification, and repeats the stopped and recorded action checks.

Customers that use an internal Agent Library can publish the included agent-library/template-card.json after administrator review. The card starts inactive and cannot be enabled until the target environment is production qualified. It identifies the exact package version, icon, connection requirements, setup guide, and support page. It is a customer library asset, not a public Microsoft marketplace listing. Customers that do not use Agent Library can import the same two solutions directly.

To remove the reference integration, remove the package agent or its actions, turn off and remove the package flows, and remove the dependent solution. Remove a user connection only after confirming that no other solution or flow uses it. Then remove the connector solution and revoke only package-specific identity access. Preserve customer business data and VeriProof evidence. Confirm that every package object is absent.

Troubleshoot connections and actions

Do not work around a failed VeriProof action by adding a direct HTTP call or another connector that can make the same business change.