Authority at the Edge: Credentials, Integrations, and Files
An AutoGPT graph can specify that a workflow should read a repository, call a model, or process a document, but the graph does not own the account or the data behind that action. This chapter examines how the Platform attaches external authority and file lifecycles to a reusable workflow, so readers can decide what belongs in a portable graph, what must be supplied at run time, and where deployment choices change the trust boundary.
A workflow needs authority it does not own
A graph is reusable precisely because it is not tied completely to one person's account. A node can declare that it needs a credential for a provider, while the task that runs the graph selects a compatible credential. The Platform's documentation supports OAuth connections, API keys, and username/password pairs. Credentials can be reused across agents, but each node or task retains a reference to the credential it is meant to use.
The reference is not the secret itself. At execution time, the executor checks the provider and credential type, resolves the actual credential, and injects a credential object into the block's run method. It also acquires the runtime lease or lock required by the credential path and releases it when the block finishes. This separation gives the graph a stable interface while leaving account authority with the user or deployment that supplies it.
That design answers a practical portability problem. Suppose a workflow searches GitHub and then posts a summary to a team channel. The workflow logic can describe those actions, their inputs, and their outputs. It should not silently carry the creator's GitHub token or messaging authority to the person who imports it. The importer must connect credentials that they are allowed to use, and those credentials may have different scopes or may not exist at all. A graph can be portable while its authority remains local.
The same boundary means that a saved graph can be valid but not runnable for a particular person. A credential can be missing, expired, revoked, mismatched with the provider, or insufficiently scoped. A cloud plan may manage some model access while still asking the user to connect an account for a personal service. In each case, the graph's structure and the user's authority are different facts. Treating a credential error as a wiring error makes debugging harder; treating a wiring contract as proof of authorization creates a security risk.
Credential selection also influences what happens before a run starts. The Platform can aggregate compatible credential inputs across a graph so the run form does not ask for a completely separate choice for every node when one reference can satisfy several compatible needs. That convenience should not be confused with unlimited authority. The executor still maps the selected metadata to the relevant node fields and checks that the resolved provider and type match what the block declared.
Provider configuration becomes a block capability
The block SDK shows how the Platform grows beyond a fixed set of built-in actions. A provider configuration can describe an API-key flow or an OAuth flow, required scopes, a base cost, and optional webhook support. A block then declares its credential field, ordinary inputs, validation constraints, and outputs. Its asynchronous run method receives the resolved credential rather than asking the workflow author to handle raw authentication in every action.
This arrangement creates a layered interface. The provider layer knows how a user connects and what kind of authority is available. The block layer knows what operation to perform and what data shape it accepts. The graph layer connects that operation to other actions.