> ## Documentation Index > Fetch the complete documentation index at: https://docs.duvo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Connections and Logins That Don't Break > Most "my agent stopped working" reports trace back to access. Set up Connections, Logins, and Secrets so they survive teammates, departures, and expired credentials. An Agent is only as reliable as its access to the systems it works in. Most "the agent suddenly stopped working" reports have nothing to do with the AOP — they trace back to a Connection nobody authorized, a Login saved as personal, or a token that quietly expired. This page covers the setup habits that prevent them. ## A Run Uses the Access of the Person It Runs As This is the single most important rule on this page. Every Run belongs to a person: a manual Run belongs to whoever clicked Start Work, and a scheduled or triggered Run belongs to **whoever created the schedule or trigger**. The Run resolves its Connections, Logins, and Secrets for that person — not for the Agent's builder, and not for the team as a whole. Two consequences follow: * **"It works for me but not for my teammate" is almost always access.** The Agent is the same; what changed is whose Connections and Logins the Run can see. * **Schedules and triggers inherit their creator's access forever.** If the creator never connected a required service, their scheduled Runs are skipped. If the creator leaves the company, their schedules and triggers keep running as them until their access dies. Before enabling a schedule or trigger, check that its creator has every Connection the Agent needs authorized under their own account. And when someone leaves the team, recreate their schedules and triggers under an active owner as part of offboarding. ## Personal Stays Personal [Logins and Secrets](/user-guide/resources/my-logins) come in two visibilities: **Team** (usable by everyone in the workspace) and **Personal** (usable only by the owner). A Run can only use items that are Team-shared or owned by the person the Run runs as. A Personal Login saved by someone else does not exist as far as the Run is concerned. The classic symptom: a teammate runs an Agent with browsing and the saved Login "isn't loading" or the site asks for credentials. Nine times out of ten, the Login exists — as someone else's Personal item. Moving it to Team fixes it. Two details worth knowing: * If a Team and a Personal item both match (same domain for Logins, same key for Secrets), the personal one wins for that person's Runs. This lets individuals override a shared default without affecting anyone else. * Connections to services like Gmail or Slack are personal by nature — each teammate authorizes their own account, and a Run uses the account of the person it runs as. For any Agent that more than one person will run, put its Logins and Secrets in Team from the start. ## When Access Breaks, Runs Degrade Quietly An expired or revoked credential usually does not stop a Run with a clean "please reconnect" error. What actually happens: the affected tool is unavailable to that Run, and the Agent works with whatever remains — which can mean improvising around the missing system instead of stopping. The Run may even look successful while doing the wrong thing. Two habits protect you: * **Tell the Agent to fail fast in the AOP.** A line like "If you cannot access \[system], stop and report the failure — do not work around it" turns a silent degradation into a clear failure you can act on. For Queue consumers, that means failing the Case with the reason. * **When a Run behaves as if a Connection vanished, believe it.** Check the Connections page, reconnect the affected account, and re-run before debugging anything else. For schedules and triggers, the platform adds a safety net: when Runs keep getting skipped because a required Connection is missing, the schedule or trigger is automatically paused and its owner gets an email. It shows up with an "Auto-paused" badge — reconnect the missing account, then switch it back on to resume. ## Test Custom Connections Before You Trust Them Custom MCP and API-key Connections point at a server you provide, and saving one does not verify it works — a wrong URL or a bad key is stored without complaint. Use the connection test when you add it, and confirm the tools it exposes look right. A dead server surfaces later as tools that silently never appear in Runs, which is much harder to trace back. See [Building Custom Connections](/user-guide/connections/building-custom-connections). ## Secrets: Attach Once, Use Everywhere Secrets are the right way to give an Agent an API key or token — never paste credentials into the AOP or a prompt. A Secret attached to an Agent is available in every Run as environment variables; the Agent sees the variable names, and the values stay inside the Run's sandbox. * Name keys the way code expects them, like `SERVICE_API_KEY` — the AOP can then reference the variable by name. * Rotate by editing the Secret's value; the next Run picks up the new value automatically. * The Team-vs-Personal rule above applies to Secrets too. ## Related Managing website Logins and env-var Secrets, Team vs Personal. Hosted, browser, custom MCP, computer use — which fits your system. Schedules and triggers run as their creator — pick owners deliberately. Include a revoked-Login drill in your pre-production test plan.