An agent's own identity for cloud work with InstaCloud
AgentID gives an agent an inbox-based sign-in to InstaCloud. The cloud service controls resource access, approvals, and billing after login.
An agent can use AgentID to sign in to InstaCloud with its own AgentMail inbox identity. The integration gives cloud work an account the service can recognize as belonging to an agent, while InstaCloud controls what that account can provision and which approvals apply.
In short
- AgentID supplies a verified inbox identity through OpenID Connect at sign-in.
- The service can tell it is admitting an agent, and can apply its own policies to that.
- InstaCloud keeps control of resources, approvals, spending, and billing.
- Sign-in is not provisioning authority and does not fund anything.
- The workflow below is proposed. Check current requirements in the service before executing.
Why does an agent need an account before it can provision anything?
For an agent asked to set up infrastructure, the account is an early dependency. Before it can request a resource, it needs to identify itself to the service that will own and bill for that resource.
An agent may already have instructions for a deployment and a place to execute them. Those instructions still need access to the cloud service.
How can a service tell an agent apart from a human at sign-in?
This is the question a cloud provider has to answer before it decides what to allow, and it is the part AgentID addresses directly.
AgentID is AgentMail's sign-in service for AI agents. It supplies a verified inbox identity through OpenID Connect, a standard protocol for accepting an external sign-in. The service receives a stable identifier and a verified email that belongs to the agent rather than to a person, and it receives them through the provider it chose to accept.
Three things follow for a service in InstaCloud's position.
The account holder is identifiable as an agent. The sign-in arrives through an agent identity provider, so the service is not left inferring intent from traffic patterns or blocking a whole class of legitimate users to be safe.
The agent has an address of its own. The InstaCloud sign-in disclosure requests the agent's name and email. The agent can use its inbox for account communication when messages arrive there, without putting a person's email address in place of its own.
The service keeps every downstream decision. Recognizing an agent at the door is not the same as granting it resources. AgentID supplies the sign-in identity. It does not select a cloud resource, set a spending budget, or authorize every operation the agent proposes. The application and cloud service still enforce those decisions.
An agent can enter with the same inbox on future visits to continue its cloud work.
Who controls what
| Stage | AgentID | InstaCloud |
|---|---|---|
| Identity at sign-in | Supplies verified agent email and stable identifier through OpenID Connect | Accepts the sign-in, decides its policy for agent account holders |
| Distinguishing agents from humans | Identity arrives through an agent identity provider | Decides what that distinction changes |
| Resource types and availability | Not involved | Defines them |
| Spending limits and funding | Not involved | Controls both |
| Approvals for an operation | Not involved | Requires and enforces them |
| Resource lifecycle and cleanup | Not involved | Owns the stop and delete operations |
| Account email | Provides the inbox behind the identity | Decides which messages it sends |
What does a bounded first task look like?
A useful first cloud task has a small scope and a clear stopping point. For example, an agent might inspect the resources available to its account, prepare a provisioning request, and ask for any required approval before proceeding.
That is a proposed starting workflow. The resource types, account setup, and funding requirements come from InstaCloud. They should be checked in the service before execution.
Why keep account access separate from resource lifecycle?
Cloud work can outlive a browser session. Signing out should not be treated as deleting a resource, and revoking an AgentID sign-in credential does not by itself end a session the provider has already issued.
When building a workflow, record what the agent created, where the resource is managed, and how to stop or remove it. The account gives the agent a way to return; resource cleanup needs its own operation.
Begin at InstaCloud sign-in. Use the AgentID sign-in guide to prepare the inbox, then follow the account and resource requirements shown by InstaCloud. Start with an action whose permissions and cost are clear.
