AI Agent Service Access: An Identity and Authorization Practice Guide

AI agents can already write code, look up information, manage calendars, and summarize data. In production, however, they often get stuck on the same problem: the services they need to reach still assume a human is on the other end. Sign-up requires an email address, login requires an SMS code, and sensitive actions require clicking a confirmation link again. An agent cannot receive these verification factors, so it has to hand the process back to a person. The more an agent is used, the more people must stay nearby to complete these steps, and the identity step cancels out the benefit of automation.

This problem cannot be solved by adding an interface that receives verification codes. Email and SMS verification assume that an account belongs to a natural person, that the verification factor can reach that person, and that the person is accountable for later actions. An agent is a software workload. It has no stable private inbox, and it should not hold a person’s session over a long period. If a person’s account, verification code, or long-lived token is handed directly to an agent, the process may work in the short term. Over time, however, it creates three risks: credential leakage, excessive permissions, and no way to tell whether an action came from a human or a program.

Define the Principals First

Access control starts with the question of who is making the call. Separate at least three types of principals instead of sharing one login.

The first is the person who starts the task. This person sets the goal, approves sensitive scope, and is accountable for the business outcome. The second is the agent that performs the task, or the runtime it runs in, such as a single task, a service process, or a set of controlled compute resources. The third is the resource being accessed, such as a bucket in object storage, a table in a database, a message topic, or an external API.

These three must not be merged into “the owner’s account.” The person approves a statement like this: this workload may perform these actions on these resources for this period of time. The workload presents its own identity. The resource verifies that this identity is still within the approved scope. With this model, a task can continue after the person has stepped away, and it does not inherit all of that person’s permissions.

Why Human Verification Should Not Be the Main Path

Common verification flows treat proof of receiving an email or text message as proof of identity. For agents, this approach has four weaknesses.

First, delivery is unreliable. Verification codes are designed for people. An agent must either rely on a person to forward the code or read someone else’s inbox. The first option interrupts automation, and the second expands the exposure of sensitive data.

Second, the factor cannot be rotated easily. After one verification succeeds, the system may cache a long-lived session. Revoking that session then requires a person to change the password or sign out of all devices, which is too coarse.

Third, responsibility is unclear. Audit logs show only one username, so it is impossible to tell whether a person or a task performed an action.

Fourth, permissions are usually granted based on what the person can do, not on what a specific task needs. The agent can easily receive far more capability than the task requires.

Verification codes can therefore serve as a supporting factor when a person grants initial authorization or confirms a high-risk action. They should not be the main path that an agent uses each time it accesses a service.

An Identity Model That Works

A more reliable engineering approach splits authorization into two steps. A person approves a policy, and the workload uses short-lived credentials.

The person completes one explicit authorization. It specifies which agents are allowed, in which environments, which resources they may access, which actions they may call, how long the authorization lasts, and whether write operations are permitted. The result is recorded as a policy. The person does not give the program their password.

When a workload starts or picks up a task, it uses an identity that the platform can verify to obtain short-lived credentials. Each credential should have an expiration time, an audience (the party it is issued for), and a permission scope. It should be discarded after use and expire automatically.

The pseudocode below shows the checks performed before one call. It does not represent the interface of any specific product. It only illustrates the order of the controls.

assert workload.identity is attested
grant = policy.lookup(workload, resource, action)
assert grant.allows(action) and grant.not_expired()
credential = issuer.issue(subject=workload, audience=resource, ttl=minutes)
call resource with credential
audit.record(who, on_behalf_of, resource, action, result)

Several fields are essential. subject is the workload, not a person’s login name. on_behalf_of records who started or approved the task. This supports accountability, but it does not transfer all of that person’s permissions to the workload. audience restricts the credential to a specified resource, so it cannot be used everywhere. ttl must be short, and write operations should have shorter lifetimes than read-only operations.

Shrink Permissions to Fit the Task

Least privilege is more than a slogan. It means denying by default and then granting permissions one at a time. Read-only queries, placing orders, modifying databases, and sending messages should be separate permissions. If an agent needs access to one table, do not grant access to the entire database. If it needs the query action of an API, do not also grant delete or payment actions.

Batch tasks and interactive tasks should also be separated. Batch tasks should have narrower and more predictable permissions. Actions involving funds, personal information, or irreversible changes should return to manual approval. An agent should not keep permanent access based on one earlier authorization.

Environments must also be isolated. Development, testing, and production should use different identities and different resources. A task that runs in testing does not mean the production identity can reuse the same long-term keys. Putting keys into prompts, code repositories, or conversation logs gives the identity to everyone who can see that text. Treat this as a configuration error, not a convenience.

Managing Secrets and Sessions

Keep long-lived secrets to a minimum. Where possible, let the runtime prove which controlled workload it is, and then have the identity service issue credentials valid for minutes. Secrets that must be stored should be kept in a dedicated key management service and injected by the runtime at startup. They should not appear in logs, model context, or error messages.

Rotation should be automated. Suspected leaks, personnel changes, policy changes, and task completion should all be able to invalidate old credentials immediately. Session persistence and “remember me” features are not suitable for agents. Each task should obtain new credentials. If that fails, the task should fail. It should not silently fall back to someone’s backup account.

If an external service only offers “a person’s account plus a verification code,” the practical approach for now is as follows. Have a person complete one authorization, limit the scope to read-only or low-risk actions, and set an expiration time. At the same time, push the service to provide an identity that programs can use, instead of expanding the ability to receive verification codes on a person’s behalf. Collecting verification codes on someone’s behalf turns the agent into a proxy for another person’s inbox. This approach is unreliable and makes compliance harder.

Auditing Should Answer Four Questions

A sound identity design is judged by whether you can answer these questions afterward, not by whether a demo can log in. Which workload performed the action? On whose behalf was it done? Which resource was affected? Which still-valid authorization allowed it?

Logs should include at least the timestamp, principal, delegation relationship, resource, action, result, and policy version. Access to the logs must also be controlled, so agents cannot read or alter their own audit records.

Anomalies should trigger alerts. Examples include the same identity accessing far more resources than usual in a short period, activity in an unauthorized environment, a credential still accepted after it expires, or a write operation without a matching manual approval record. Teams should use these signals to reduce permissions and revoke credentials, not to help anyone work around the controls.

A Rollout Sequence

Proceed from the lowest risk to the highest. Do not try to make every service log in automatically from the start.

First, inventory the resources and actions the agent actually needs, and remove temporary channels such as “use my account for now.” Next, create a separate identity for each runtime environment, granting only read-only access to non-production resources. Verify that short-lived credentials, expiration, and revocation work as intended.

Then move production read-only queries to machine identities, and confirm that all audit fields are complete. Only after that should you consider limited write operations, with manual approval, shorter validity periods, and narrower resource scopes. Payments, permission changes, bulk deletions, and sending external messages should stay at manual confirmation points by default. Keep them there until the policy, auditing, and rollback have been checked and hold up.

When implementing on a cloud platform, you typically use general-purpose capabilities: identity and access management, key management, audit logging, and monitoring and alerting. If you use Baidu AI Cloud, keep the design within these general categories. Let workload identities exchange for short-lived permissions, keep keys out of conversations and code, and make sure every call leaves a traceable record. There is no need, and no reason, to assume the platform will build custom integrations for specific business needs that were not agreed upon.

Common Pitfalls

Automating away multi-factor verification is not progress. It only turns the human factor into a secret that can be forwarded. Giving an agent a super administrator account so that it can “run first” means one prompt injection or one log leak becomes a full data exposure risk. When multiple agents share one service account, it becomes impossible to tell which task caused a problem. Testing only successful logins, without drills for expiration and revocation, means the policy exists in name only.

A reasonable acceptance standard has four parts. People no longer forward verification codes for routine read-only calls. If a credential leaks, the impact window is measured in minutes, not in the lifetime of the account. Audit records separate people from workloads. Unauthorized access is rejected at the policy layer, rather than depending on the agent to be careful.

An agent’s productivity comes from continuous execution. The value of an identity system comes from being able to stop that execution at any time. What connects the two is verifiable principals, expiring authorizations, and auditable records.