Confirm identity and access for each approach
An integration approach that fits a business need still has to pass a practical test: can the agent connect to it, and is the agent allowed to use it the way it needs to? This unit describes how you can validate that you have the appropriate identity and access for each approach.
Decide whose identity the agent acts as
When the agent uses a tool, the tool connects to a system under an identity. That identity determines what the agent can see and change.
- End-user credentials: Each user signs in, and the agent reaches only what that user is permitted to access. This option fits requests that should respect individual permissions, or actions that should be recorded under the person who made the request.
- Maker-provided credentials: The agent uses the credentials of the maker who set up the tool, for everyone who uses the agent. This option fits systems that users don't have their own access to. Everyone who uses the agent can then reach whatever those credentials can, so limit their permissions to what the agent needs.
For example, a case update might need to be recorded under the staff member who requested it, while a case lookup might use one set of credentials that the utility's IT team approves for the agent.
Decide the identity for each approach before you look at connection details. The answer affects which authentication method you choose and who needs access to the system.
Check the connection requirements for each approach
Each approach has its own connection requirements, and no single authentication method applies to all of them. Use this table to check the approaches you shortlisted:
| Approach | What to confirm |
|---|---|
| Connector | Some connectors ask you to sign in or provide credentials when you add them. Confirm that you can create the connection and that the connector includes the actions you need. |
| MCP server (preview) | The server must be reachable, and you need the credentials its authentication method requires, such as an API key or a client ID and secret. Ask the server's owner which method it uses. |
| Foundry IQ | You need access to the knowledge base, which is granted in Microsoft Foundry. The connection supports API key, client certificate, service principal, or Microsoft Entra ID Integrated authentication. Each agent can have one Foundry IQ connection. |
| Fabric IQ (preview) | You need access to the Fabric workspace and semantic model, plus any credentials that your Fabric configuration requires. |
| Work IQ (preview) | Your tenant must be enabled for Work IQ. You create a connection, sign in, and allow Work IQ to connect to services when prompted. |
| Connected agent | The other agent must be powered by the GitHub Copilot harness, in the same environment, published, and configured as available to connect. You must own it or have it shared with you. |
When a need involves making changes, match access to the operation. A connection that supports reading cases doesn't necessarily support updating them. For example, a need that sends email through Work IQ depends on an administrator turning on Work IQ's write operations.
A connected agent runs with its own instructions, knowledge, and tools, so what it can access and change depends on how its owner set it up. Before you recommend handing work to it, ask its owner what it can access and change, and confirm that the checks your design requires, such as approvals, still apply.
Confirm that your environment allows it
An approach can pass every check so far and still be unavailable where the agent runs.
- Data policies: Your organization can block specific tools and connectors. A blocked tool appears disabled when you try to add it, with a message that explains the restriction. This blocked-tool experience is currently in preview. Changing the policy requires an administrator.
- Credential policy: An administrator can turn off maker-provided credentials for an environment. Tools then connect with end-user credentials, and users sign in when a tool needs it. Check this setting before you recommend that a tool use the maker's credentials.
- Availability: The knowledge sources you can add vary by environment and licensing. MCP servers, Fabric IQ, and Work IQ are in preview on this harness, and preview features aren't meant for production use.
- Target environment: Check the environment where the agent runs in production. An approach that's available in a development environment might be blocked in production.
Record what you confirmed and what's still open
A strong recommendation comes with documented evidence. For each approach, record the identity it acts as, the connection requirements you confirmed, the result of the policy check, and anything that's still unresolved. When an approach is blocked, say so and note what would unblock it, such as an administrator changing a policy or a team sharing an agent with you.
Reflect: Think of one system an agent you work on needs to reach. Whose identity should the agent use there, and how would you confirm access?
With access confirmed, the remaining question is whether the agent picks the right capability when a request arrives.