The security conversation around AI agent credentials focuses almost entirely on scope — which permissions the agent has. Scope matters. But token lifetime is the variable that determines your actual blast radius when something goes wrong. A narrow-scoped token that lives for 90 days is more dangerous than a broad-scoped token that expires in 4 hours.
The math on breach window
When an OAuth token is compromised — through a leaked log file, a misconfigured environment variable, a container image pushed to a public registry — the attacker's window of opportunity is exactly equal to the token's remaining lifetime. If your agent tokens don't expire, that window is infinite. If they expire in 4 hours, the window is at most 4 hours from the moment of compromise.
Scope affects what the attacker can do. TTL affects how long they can do it. Both matter, but TTL has a hard ceiling. You can tighten scope to zero and still have a problem if a token with zero scopes is compromised and used for recon. You can set TTL to 1 hour and your breach window is at most 1 hour regardless of scope.
The practical consequence: a GitHub token with read:org scope and a 30-day TTL is more dangerous than a repo:write token with a 2-hour TTL, because the attacker using the read-only token has 30 days to enumerate your organization structure, map your repositories, and build a target list for a subsequent attack. The write-access token expires before they can act on that reconnaissance.
What default TTLs look like in practice
Most OAuth providers issue tokens with default lifetimes that were designed for human users, not automated agents. GitHub's OAuth app tokens do not expire by default — they remain valid until explicitly revoked. Google's OAuth 2.0 access tokens expire in 3,600 seconds (1 hour), but the refresh tokens can last indefinitely. Slack user tokens do not expire unless the user or app is removed. Salesforce connected app tokens default to a 2-hour session but connected apps configured for "offline access" get indefinite refresh tokens.
When an AI agent authenticates against these providers and stores the resulting tokens in an environment variable or a secrets manager, the effective TTL is whatever the provider issued — which is often much longer than any reasonable security requirement would dictate. The team that set up the agent rarely revisits this.
We reviewed 28 agentic deployments across our beta customer base. Average token lifetime at the time of review: 14.3 days. Shortest: 1 hour (a team that had recently experienced a token leak and over-corrected). Longest: 2,190 days (a team that had rotated credentials manually once in six years, for a legacy integration that nobody wanted to touch).
The rotation problem: why teams don't enforce TTLs manually
If short TTLs are clearly better for security, why do most teams run long-lived tokens? Because rotating credentials manually is painful. It requires updating every environment variable, every secrets manager entry, every CI/CD pipeline that uses the credential. For a small team with one or two integrations, that is a 20-minute task. For a mid-size engineering organization with 15 agents, 12 OAuth integrations, and 8 deployment environments, manual rotation becomes a multi-day project that nobody wants to own.
The result is a rational security failure. Teams know their tokens should rotate more often. They do not rotate them because the cost of rotation is high and the probability of compromise appears low. That calculation shifts immediately after a breach — which is too late.
Alter's approach is to move rotation entirely out of the human workflow. When an agent requests a token through Alter, it gets a short-lived token (default 4 hours, configurable down to 15 minutes). When the token expires, the agent requests a new one. Alter handles the OAuth exchange. The agent never holds a long-lived credential. There is no rotation task because there is nothing to rotate — every token minted through Alter is already at minimum viable lifetime.
How to pick the right TTL for different agent types
Not all agents need the same TTL. The right TTL depends on task duration, error recovery requirements, and how often the agent runs.
Batch processing agents — agents that run scheduled jobs, data pipelines, or nightly sync tasks — typically complete a run in under 30 minutes. A 1-hour TTL gives them enough runway with a 30-minute buffer for retries. There is no reason these agents should carry credentials that survive past their run window.
Long-running assistant agents — agents that operate interactively or stay alive for hours — need longer TTLs but can use refresh tokens rather than long-lived access tokens. A 4-hour access token with a refresh token that requires re-authorization every 24 hours is a reasonable balance for most interactive agent use cases.
Event-driven agents — agents that wake up on a webhook, process a single event, and shut down — should use per-run tokens. Each agent activation gets a fresh token with a TTL of 1 hour. If the activation takes 3 minutes, the token is valid for 57 minutes before expiry. That is acceptable residual risk.
High-sensitivity agents — agents accessing financial records, PII, healthcare data, or security-relevant systems — should use tokens with the shortest TTL that does not cause operational failures. For most sensitive use cases, 15-30 minutes is achievable without impacting performance, especially with a proxy that handles the re-authentication transparently.
TTL and the audit trail relationship
Short token TTLs have an underappreciated secondary benefit: they create natural audit checkpoints. When an agent must re-authenticate every 4 hours, Alter creates a new audit log entry for each authentication. That log entry captures the agent's state: which task it is running, which scopes it is requesting, how its scope requests compare to its policy. A long-lived token creates one audit entry at issuance and then disappears from the audit view.
In incident response, this matters enormously. If you are trying to understand what an agent did between Monday morning and Thursday afternoon when you discovered the breach, a log of re-authentication events gives you natural time anchors. "The agent requested new credentials at 9am, 1pm, and 5pm Tuesday" tells you exactly when it was active. A single token issued Monday morning tells you nothing about when the agent actually ran.
Implementation: adding TTL enforcement without rewriting your agents
The clean way to enforce short TTLs across an existing agent fleet is at the proxy layer. Your agents continue to call the same OAuth endpoints they always have. The proxy intercepts each request, checks the agent's policy, and issues a short-lived token instead of passing through the provider's default lifetime. The agent receives a token that works exactly like a normal token. It just expires sooner.
Agents that handle token expiry correctly — which most well-written agents do, since any network call can return a 401 — will automatically re-authenticate when the token expires. The re-authentication hits the proxy, which checks the policy again and issues a new short-lived token. The agent proceeds. The entire cycle is transparent to the agent's business logic.
The one failure mode to watch for: agents that cache tokens in application memory and do not check expiry before use. These agents will fail when a short-lived token expires mid-run. The fix is always a code change — add an expiry check before credential use — but it is a small change and one that improves the agent's resilience to normal token expiry from any cause, not just Alter-enforced short TTLs.
The bottom line
If you have AI agents running in production today and you have to choose one security improvement to make this week, make it this: find your longest-lived OAuth tokens and cut their TTL in half. Do not wait for a full audit. Do not wait for new tooling. Find the tokens that expire in 90 days and set them to 45. Find the ones that expire in 30 days and set them to 7. That reduction in breach window is real, immediate, and costs you nothing except the one-time effort of the rotation.
Once that is done, invest in automation that keeps it that way. Manual TTL management degrades. Teams change. Integrations accumulate. The only durable solution is tooling that enforces short lifetimes by default on every token, every time, without requiring anyone to remember to do it.