HTTP and MCP credentials: secure access for voice agents

Distinguish the keys

Confirm which system supplies the key and which connection will use it. A CRM access key does not automatically work for a booking system. Ask the service owner for an account permitted to perform only the agent’s tasks.

Services may require different ways of presenting a key. Use the authentication type specified by the integration owner and complete the matching fields in Tigy. A correct key placed in the wrong field can prevent the connection.

Attach the credential to the tool

Open the HTTP or MCP tool and select a workspace credential or create the required one. Complete the authentication type and displayed fields, associate the credential and save. Run a test lookup.

Keep secrets out of agent instructions, examples and public content. Prefer a test account restricted to necessary data and operations.

Investigate the failure type

A 401 response may indicate a missing or expired key or incorrect format. A 403 may mean the account is recognized but lacks access to the operation. Consult the service documentation and logs for the specific case.

For a connection that never reaches its destination, investigate the URL, availability and network. Rotating a key does not fix an unreachable server.

Make access part of maintenance

When an external service secret changes, update the associated credential and repeat the lookup before publishing changes. Record the integration owner and test procedure.

A prompt can limit actions the agent tries to perform. Effective authorization must exist in the external service, including for requests with unexpected parameters.

Keep secrets outside conversations and public review

Use appropriate credential and header mechanisms. Do not place tokens in instructions, retrievable documents or repeatable examples. Secrets can also appear in URLs and errors; review adapter output.

Share failures using statuses, identifiers and reduced descriptions without sensitive headers. Diagnosis needs evidence, not credentials copied into tickets and spreadsheets.

Test expired and insufficient-access credentials. Speech should explain incomplete retrieval without reading internal details. Investigate the refused action and necessary permission before broadening access.

Prepare rotation without disrupting service

Record credential dependencies, replacement verification and retirement steps. Inventory dependent tools so rotation does not fix one agent while breaking another. Verify the environment.

After replacement, test an authorized lookup and an operation that should remain refused. The latter checks that permissions did not broaden. Writes need controlled data and timing.

Assign emergency-revocation ownership. Suspected exposure requires replacement in the responsible system and review of usage. Removing a prompt sentence does not invalidate an already disclosed secret.

Identify which system authenticates which caller

Tool credentials allow the agent to access external systems. Use the secret issued by the destination service and keep it outside the instructions. Before filling configuration fields, trace the request: sender, receiver, resource and service issuing the credential.

Consider a fictional order lookup. The tool requests information from the store’s system, which requires its own access key. Settings must use a key accepted by the store and the format specified by the integration owner. The caller does not need to provide that key, and it should stay out of the agent’s instructions.

Maintain a simple inventory containing service, purpose, owner and environment. Do not copy secrets into it. Useful maintenance information identifies which account authorizes retrieval, permitted operations and who can rotate access. Without this association, failures can prompt changes to a key unrelated to the tool.

Separate customer context from integration identity too. Credentials authenticate system-to-system requests; identifiers collected in conversation select records. Neither removes the need to verify authorization for the specific record. External servers should check that relationship before returning data.

When several tools share an account, document that dependency. Changing one credential can affect multiple service tasks, so the verification plan should include each dependent operation rather than only the tool used to investigate the original error.

Follow the service format rather than an assumed convention

In Tigy, select or create the credential in the tool settings. The form changes according to the access type required by the service. Ask the integration owner for the correct type and required values. Do not replace one option with another simply because they all use a key: each service expects access to be presented in a particular way.

Check header name and value structure. Authorization and X-API-Key can represent different contracts. A valid secret sent in the wrong place remains rejected. Use the service's own documentation to configure it; do not compensate by asking the model to insert secrets into conversational parameters.

After association and saving, run a known test lookup. Inspect external results where possible. Interface acceptance does not establish that the destination recognized authentication. Start with a resource and operation the account definitely permits, separating formatting from authorization.

Avoid real customer data in this trial. Prepare a fictional record in an authorized testing environment. For tools with effects, use test accounts and destinations not communicating with customers. The objective is validating access and contracts without turning technical investigation into business action.

If the result is rejected, preserve the request's relevant structure without exposing the secret. Owners need method, destination and authentication type to investigate. They usually do not need a full credential copied into a message, screenshot or public issue.

Choose permissions proportional to tasks

Credentials should match what the agent needs to execute. If a pilot only retrieves status, permission to delete records adds no task value. Ask the external-system owner for access limited to required operations and data. Catalog filtering and prompts guide conversation, while permission must exist in the executing service.

Distinguish reads from writes and test environments from production. A test lookup must not accidentally reach live records. Creation tools should not send messages or trigger charges while staff are evaluating parameters. Identify destination and credential together, because changing only URL or only secret can mix environments.

Test rejection as well. Request a resource outside authorized access and verify server denial. Conversation should explain the boundary without disclosing denied-resource details. A correctly handled negative result establishes functioning scope, not an immediate need for broader permission.

Review access when service scope changes. Adding cancellation to an agent previously limited to order lookup requires another contract and authorization. Make that decision deliberately, including confirmation criteria and duplicate prevention. Do not widen an entire account simply to avoid planning the capability.

Schedule ownership review when people or systems change. An integration account without a responsible owner can remain active long after its original purpose disappears. The inventory provides a practical starting point for deciding which access is still necessary.

Distinguish authentication, authorization and connectivity

Tigy documentation gives practical clues: 401 can indicate missing, expired or incorrectly formatted credentials; 403 can indicate a recognized account lacking access to the resource or operation. Treat codes as clues and confirm the external service contract. Do not interpret every rejection as a need for a more powerful key.

Connection failure requires different investigation. Incorrect URLs, unavailable destinations or network access can block calls before authentication. Rotating secrets does not make servers reachable. Identify the failing stage to avoid unnecessary changes and loss of previously working configuration.

When several tools fail simultaneously, inspect shared dependencies. They may share a service, credential or permission change. When only one operation fails, compare method, resource and contract. This distinction narrows causes without rewriting every agent instruction.

In conversation, explain only what customers need. They do not need header or secret details. They need to know retrieval did not complete and which alternative is available. Do not invent results to hide failure or ask callers to repeat information when the cause is system-to-system access.

Record how the error was confirmed and which test will establish repair. Successful authentication alone is insufficient if the account still cannot execute the intended task. Verification should reach the same meaningful operation that originally failed.

Rotate with a continuity check

When external services change secrets, update associated credentials and repeat retrieval before publishing dependent changes. Coordinate with the owner and identify tools sharing access. Rotation completes when required tasks still work and old access is handled under the service's process.

Do not copy secrets into prompts as a temporary workaround. That creates exposure and another copy to maintain. Use appropriate storage and verify workspace and tool association. Tests using another credential can pass without establishing the configuration serving customers.

Retain the trial case for future rotations. A small lookup with a known result verifies continuity without relying on live calls. For writes, use a controlled outcome and check that no duplicate effects were created.

Record the change date and verification result without storing secret values in editorial or operational notes. This gives future maintainers useful evidence while keeping authentication material in its intended configuration.