API keys are credentials, OAuth governs access, and JWT is a token format. Compare their roles for AI agents with six reproducible authorization fixtures.
By Yuki Yu
An API key is a credential, OAuth is an authorization framework, and JWT is a token format. An AI agent may encounter all three in one workflow. Choose the access mechanism for each service, then enforce which user, tenant, tool and action the agent may act for. A valid credential alone does not establish permission for every proposed action.
This distinction matters when an assistant can both call a model and operate a business tool. The credential that pays for inference does not automatically authorize access to a customer's documents or permission to publish a result.
Read first: The AI API key security guide covers credential handling. This article focuses on choosing and separating access mechanisms for an agent workflow.
How are API keys, OAuth and JWT different?
They answer different design questions. An API key supplies a credential accepted by a service. OAuth defines how a client obtains limited access. JWT defines how claims can be represented in a token.
Term
Role
What it does not establish by itself
API key
Service-specific credential associated with an account, application or workspace
The current user's permission for a business action
OAuth
Framework for obtaining and using limited access to a resource
The quality or appropriateness of an agent's proposed action
JWT
Format for carrying claims, with protection depending on its construction and validation
A complete authorization flow or a safe execution decision
RFC 6749 defines OAuth access on behalf of a resource owner or on a client's own behalf. RFC 7519 defines JWT. An OAuth access token can use JWT, but the two terms are not synonyms. A provider may use an opaque access token instead.
Similarly, an HTTP Authorization: Bearer header does not prove that the credential was issued through OAuth or that it is a JWT. Follow the target service's documented authentication contract.
When does an agent backend use an API key?
Use a service's API key when that is its documented server-side credential mechanism. Keep it behind a controlled backend and apply your application's authorization before using it.
For example, Token360's authentication documentation describes an API key sent in the Authorization header and advises backend use rather than exposing the key in browser or mobile code. That supports a model-inference connection; it does not establish OAuth delegation or JWT acceptance for Token360.
A customer-facing agent should not receive the provider key in its prompt or pass it as a tool argument. The backend can choose an approved connection after checking the requested operation. Use an internal connection reference in application records, with secrets resolved only by the component that makes the authorized call.
A shared account key can otherwise hide who initiated an operation. Preserve a separate user and tenant record so you can attribute requests without assuming the provider credential identifies each end user.
When is OAuth relevant to an AI agent?
OAuth is relevant when a connected service uses it to grant an application limited access, including user-delegated access. It can help separate a customer's grant from your own model-provider credential.
Consider an assistant that reads a customer's calendar and drafts a summary using a model. Calendar access and model inference have different owners and permission boundaries. Store the customer's connection separately from the provider connection. Do not substitute your organizational credential for a missing customer grant.
For implementation choices, use the current OAuth security best current practice, RFC 9700, rather than a historical tutorial alone. It updates earlier guidance and includes access-token privilege restrictions, redirect-flow protections and replay defenses. The exact grant and controls must match the client and resource service.
Even an appropriate OAuth grant does not approve every agent decision. A permission to create a draft is narrower than a user's instruction to publish that specific draft. Your product still needs to connect the proposed action to the user's current intent.
What does a JWT tell you, and what must you verify?
A JWT can carry claims about a subject and intended use, but reading its payload is not validation. Use an established validator configured for the issuer and token profile your application actually accepts.
RFC 8725 calls for algorithm verification, cryptographic validation and checks on issuer and audience, among other measures. Apply the required lifetime and token-type rules for your profile. Do not trust a request's arbitrary issuer or key location simply because the token names it.
A signed JWT is not necessarily encrypted. Avoid putting secrets in a readable claims payload. Also avoid treating a token intended for one service as permission to call another. Validity for the intended recipient is a different question from whether a string has the familiar JWT shape.
The token's identity and permissions still need to meet the application's resource-level policy. The receiving tool should check the actual target object, not merely whether some token was supplied.
A proposed application boundary. It is not a claim that one provider implements every control.
Can an authenticated agent still make an unauthorized request?
Yes. Authentication and operation authorization are separate checks. A known principal can request the wrong tenant, tool or action, or exceed a current budget or approval.
We ran a small offline policy exercise on November 3, 2026. It starts with an assumed authenticated principal for tenant A, permission to create drafts and access to a draft service. Each fixture changes one proposed request. No API keys, OAuth server, JWT parser or network requests are involved.
Fixture
Change from approved request
Observed policy decision
Approved draft
None
Allow
Other tenant
Request targets tenant B
Deny: tenant mismatch
Publish action
Request asks for draft:publish
Deny: permission missing
Other tool
Request uses publish-service
Deny: tool not allowed
Over budget
Estimated cost 6; available budget 5
Deny: budget insufficient
Approval missing
No current approval
Deny: approval missing
All six cases share the same assumed principal, yet only one is allowed. These are deliberately constructed functional cases, not a security benchmark or proof of production enforcement. The budget numbers are arbitrary units, not provider prices.
Offline fixtures isolate the distinction between identity and operation permission.
Example image fixtures: . Run python3 policy_demo.py with Python 3.9 or later; no external package or credential is needed.
Copy policy_demo.py:
"""Offline policy fixtures only. No credentials, JWT validation, network or production enforcement."""
import json
principal={'tenant':'A','permissions':['draft:create'],'allowed_tools':['draft-service']}
def decide(request):
if request['tenant']!=principal['tenant']:return 'deny: tenant mismatch'
if request['permission'] not in principal['permissions']:return 'deny: permission missing'
if request['tool'] not in principal['allowed_tools']:return 'deny: tool not allowed'
if request['estimated_cost']>request['available_budget']:return 'deny: budget insufficient'
if not request['approval_current']:return 'deny: approval missing'
return 'allow'
base=dict(tenant='A',permission='draft:create',tool='draft-service',estimated_cost=2,available_budget=5,approval_current=True)
variants=[('approved draft',{}),('other tenant',{'tenant':'B'}),('publish action',{'permission':'draft:publish'}),('other tool',{'tool':'publish-service'}),('over budget',{'estimated_cost':6}),('approval missing',{'approval_current':False})]
results=[dict(case=name,request=base|changes,result=decide(base|changes)) for name,changes in variants]
assert [r['result'].split(':')[0] for r in results]==['allow','deny','deny','deny','deny','deny']
print(json.dumps({'scope':'Assumed authenticated principal; local policy exercise only','results':results},indent=2))
The exercise omits token validation, revocation, persistence, concurrent budget reservation and real approval storage. In production, derive identity and approval from trusted server-side state. Do not accept a caller's self-declared tenant membership or approval flag as evidence.
Where should authorization run in an agent workflow?
Enforce authorization at the component that executes the action, using the current resource and request. An instruction inside the model prompt is not a substitute for that check.
Separate proposal from execution. The model proposes a tool and arguments; the application resolves the actual target, verifies permission and applies any required approval before dispatch. If the target, recipient or amount changes after approval, check whether a new approval is required.
Keep model inference and tool execution separately observable. A successful model response does not mean the proposed business action ran, and a failed model call does not prove that a previous tool action was rolled back. Record each outcome explicitly.
The AI API governance implementation guide covers broader enforcement design. This article's narrower decision is which credential and grant belong to each connection.
What evidence should you retain without logging secrets?
Retain enough context to explain an allowed or denied action, while keeping credentials out of routine logs. The useful record links a principal, tenant, connection reference, requested operation and decision.
Add the policy version, timestamp, target resource reference and approval record where applicable. Keep the serving model request separate from the tool action ID. Avoid logging complete keys or bearer tokens simply to make troubleshooting easier.
When access ends, verify each affected connection's lifecycle independently. The API key offboarding checklist addresses key cutoff and closure evidence. Do not assume that revoking one credential cancels already submitted work or removes every other grant.
Frequently asked questions
Is OAuth safer than an API key in every situation?
No universal comparison follows from the label. Match the service's supported mechanism, ownership model and required controls.
Is JWT an alternative to OAuth?
No. JWT is a token format; OAuth is an authorization framework. OAuth deployments may use JWT-formatted access tokens.
Does a Bearer header mean OAuth is being used?
No. Inspect the service's documented credential issuance and validation process.
Should an agent see the model provider's API key?
The backend should resolve the provider credential for authorized calls. The model does not need the secret in its prompt or tool arguments.
Does a valid token authorize every tool call?
No. The requested resource, tenant, permission and current application policy still matter.
Were the six fixtures tested against Token360?
No. They exercise a small local application policy after assumed authentication. They do not validate any live provider's security controls.
Prompt Library
Insights
Insights