Where a credential can be sent
Found this helpful? Share it:
Found this helpful? Share it:
Every connection carries rules describing the addresses it may reach. They are what lets an agent call a service without naming a credential: idapt matches the address against the rules and attaches the one that fits ๐ฏ
Two things, and it helps to keep them apart:
Picking the right credential. With a rule for
github.com, a call to api.github.com gets your
GitHub token without anyone naming it.
Limiting how far it travels. A rule states where a credential is willing to go, so an ordinary mistake, like a wrong host in a generated address, does not present a live key to a stranger.
Rules are routing, not a permission system. An agent allowed to use a credential can also widen its rules, and that is deliberate so the no-setup behaviour works. Treat rules as a way to keep mistakes small, and use Human only for anything no agent should touch.
| Kind | Matches | Use it when |
|---|---|---|
| Domain and subdomains | github.com and anything under it |
Almost always. This is the default. |
| Exact host | Only api.github.com, port included |
One host of several should have it. |
| Starts with | Addresses beginning with what you type | Only one part of an API should have it. |
| Exact address | One address, ignoring the query string | A single endpoint, such as a webhook. |
| Matches pattern | Addresses matching a regular expression | Nothing simpler fits. |
| Never send here | Blocks an address the other rules would allow | Carving an exception out of a broad rule. |
Never send here is checked first and always wins. It is the rule people reach for most after the default: hold a credential for a whole domain, but never send it to one particular host under it.
Underneath the rules, the editor writes out what they mean in a sentence. That sentence is the thing worth checking before you save. A list of rules is precise and hard to read; working out what it does means holding several of them in your head at once, including which one wins.
If a credential exists but its rules do not cover the address, the call
fails with uri_rule_mismatch and the message names the
exact command to widen it. An agent can usually recover on its own turn.
Widening is recorded in the credential's activity.
If two credentials match equally well, such as a work and a personal account for the same service, idapt refuses rather than guessing and lists them by account label. One extra turn is cheap; using the wrong account can charge a real customer.
Give a second account for the same service a description. It is what the agent uses to tell them apart.
An SSH key, a database password, or a certificate has no address to be sent to. Those live under Secrets, carry no rules, and are never attached to a request on their own. You mount them by name on a computer, a container, or a function.
Related articles
Connect a service to your agents
Store one credential for a service, and an agent can use its API, its MCP server, or its command-line tool without any further setup.
Credentials
Store API keys and app connections once, then let your commands, functions, and agents use them without pasting a key into a chat.
Was this helpful?