AI agents are becoming the primary way software interacts with external APIs. A single agent might read from Google Calendar, post to Slack, create a GitHub PR, and query Datadog, all in one task.

Today, most teams handle this with scattered environment variables, hardcoded tokens, and ad-hoc authorization logic bolted on after the fact. The result: tokens stored in plaintext databases, no visibility into which agent accessed what, no way to revoke access without redeploying, and zero audit trail when something goes wrong.

It works until it doesn’t. And when it doesn’t, you have no idea what happened.

What Alter Vault does

Alter Vault is the authorization layer for AI agents. It sits between your agents and the APIs they call. Every request flows through the vault, which handles three things:

Encrypted credential storage. OAuth tokens and API keys are stored in an encrypted vault — never in your application database. Your code only holds a reference ID. Tokens are automatically refreshed before they expire, so agents never hit a 401.

Identity-aware policy enforcement. Every request is checked against two identities: the end user who authorized the connection and the agent making the request. Policies define which agents can access which APIs, with what scopes, during what time windows. Unauthorized requests are blocked before they reach the provider. Fail-closed by default — if a policy can’t be evaluated, the request is denied.

Dual-identity audit logging. Every API call is logged with full context: the organization, the end user, the agent, the specific tool invocation, and the result. You get a complete chain of custody for every action, ready for SOC 2, GDPR, or HIPAA compliance.

Two types of credentials, one API

Alter Vault supports two credential types, both accessed through the same alter_app.request() method:

OAuth connections are end-user authorized. A user clicks “Connect Google” in your app, authorizes access through the standard OAuth flow, and the tokens are stored encrypted in the vault. The user can see and revoke their connections from the Wallet Dashboard at any time.

Managed secrets are developer-stored. API keys, service tokens, and other credentials that don’t require end-user authorization — stored through the Developer Portal and accessed with the same alter_app.request() call. Supports Bearer tokens, API keys, Basic Auth, and AWS SigV4.

How a request flows through the vault

When an agent calls alter_app.request(), five things happen in under 15ms:

1. Identity resolution — The vault resolves the full chain: organization, app, end user, and agent. If the agent registered with a run_id or thread_id, those are captured too.

2. Policy evaluation — Access policies are checked against the resolved identity. Scope restrictions, time windows, and custom rules are all evaluated. If any check fails, the request is denied immediately.

3. Token retrieval — The encrypted credential is decrypted from the vault. If the token is expired, it’s automatically refreshed before injection.

4. Request proxying — The token is injected into the authorization header, and the request is forwarded to the provider. Connection pooling and retry logic are built in.

5. Audit logging — The full request is logged with both identities (end user + agent), the policy decision, the provider response, and latency.

Agent identity tracking

When multiple agents access the same credentials, you need to know exactly which agent did what. Alter Vault tracks agent identity at two levels:

Agent registration — each agent type (e.g., “scheduling-bot”, “data-pipeline”) is registered once. Every request from that agent is attributed to it in audit logs.

Per-request context — for agent frameworks like LangChain and LangGraph, pass run_id, thread_id, and tool_call_id on each request. This gives you full traceability through multi-step agent workflows, down to the individual tool invocation.

from alter_sdk import App, ActorType, HttpMethod

alter_app = App(
    api_key="alter_key_...",
    actor_type=ActorType.AI_AGENT,
    actor_identifier="scheduling-bot",
)

response = await alter_app.request(
    grant_id,
    HttpMethod.GET,
    "https://www.googleapis.com/calendar/v3/calendars/{calendar_id}/events",
    path_params={"calendar_id": "primary"},
    query_params={"maxResults": "10"},
    run_id="run_abc123",
    thread_id="thread_xyz",
)

The TypeScript SDK has the exact same interface:

import { App, ActorType, HttpMethod } from "@alter-ai/alter-sdk";

const alterApp = new App({
  apiKey: "alter_key_...",
  actorType: ActorType.AI_AGENT,
  actorIdentifier: "scheduling-bot",
});

const response = await alterApp.request(
  grantId,
  HttpMethod.GET,
  "https://www.googleapis.com/calendar/v3/calendars/{calendar_id}/events",
  {
    pathParams: { calendar_id: "primary" },
    queryParams: { maxResults: "10" },
    runId: "run_abc123",
    threadId: "thread_xyz",
  },
);

Three ways to connect end users

Alter Connect supports three trigger methods depending on your application type:

• Headless — for CLI tools, scripts, and Jupyter notebooks. The SDK opens a browser for the user to authorize, then returns the connection.

• Redirect — for server-rendered apps. Your backend redirects the user to the hosted Connect page, and they’re redirected back after authorization.

• Popup — for SPAs. The @alter-ai/connect frontend SDK opens a popup window with the provider picker. No page navigation required.

All three methods result in the same thing: an encrypted credential in the vault and a connection ID your app can use with alter_app.request().

60+ providers, zero provider-specific code

Alter Vault supports 50+ OAuth providers out of the box — Google, Slack, GitHub, Notion, Atlassian, Salesforce, HubSpot, Linear, and many more. Once a provider is configured in the Developer Portal, your agents access it through the same alter_app.request() call regardless of the provider. No provider-specific token handling, no refresh logic, no scope management.

Get started

Install the SDK and make your first authenticated API call in minutes:

pip install alter-sdk

npm install @alter-ai/alter-sdk

Read the full documentation to learn more, or sign up at the Developer Portal to create your first app.

←

If true, the ramifications on how we think about human work and society are enormous. Much of the digital software we interact with today could become agentic. Given a shift of this magnitude, it is only natural that entirely new categories of products begin to emerge to support this world.

At the same time, some skepticism is warranted. Is agentic software really that different? Can the problems we solved in traditional software not be reapplied here? After all, we have already built systems for machine-to-machine interaction. Is this not simply another rendition of existing machine-to-machine auth problems?

While the initial skepticism is natural, agentic systems do introduce fundamentally different authorization challenges. To understand why, it is worth stepping back and examining how agentic systems differ from traditional software.

To be precise, while often referred to broadly as “auth,” the most significant new challenges for agentic systems lie in authorization rather than authentication.

What are agents

Traditional software is built around deterministic execution, a predefined set of rules that dictate how the system behaves. Each step in the flow is explicitly designed, and the system is expected to operate within a well-understood set of states. When a scenario is not accounted for, the system enters a state that is typically classified as a bug. Much of the software engineering lifecycle, from design to testing, is centered around ensuring that these states and transitions are well understood and controlled.

Agents represent an evolution of this model. At a high level, most agents consist of a probabilistic, non-deterministic decision-making component, often an LLM, that determines what to do next, and a set of tools, APIs, services, or functions that are no different from traditional deterministic software, executing predefined logic. The difference is not in the tools themselves, but in how they are selected and composed. Rather than following a fixed flow, the agent dynamically decides which tools to use and in what sequence.

This introduces a fundamental shift. Instead of being purely deterministic, agentic software combines deterministic modules with probabilistic decision-making that drives key parts of execution. The system is no longer just executing predefined steps, it is deciding what to do next.

As a result, agentic systems can enter states that were not explicitly anticipated during development, allowing them to handle problems that are impractical to fully specify ahead of time.

To make this more concrete, consider a simple agent tasked with scheduling a meeting:

In a traditional software system, the flow might look like:

• parse structured user input and extract required fields (date, time range, participants)

• validate inputs and map them to predefined parameters

• query calendar systems using fixed API calls with known schemas

• compute availability and suggest time slots based on predefined rules

• confirm selection and create the event via a deterministic booking flow

Each step is explicitly defined, with well-understood inputs, outputs, and state transitions. The system operates within a predefined flow, where every possible path has been anticipated and implemented ahead of time.

Now consider an agent performing the same task. Instead of following a fixed flow, it might:

• interpret vague instructions like “sometime early next week” and convert them into concrete time ranges for tool execution

• infer relevant participants from context and resolve identities via directory APIs

• call calendar and availability APIs across systems to assemble a real-time view of schedules

• use messaging tools to propose times, gather responses, and iteratively resolve conflicts

• adapt mid-execution through additional tool calls, updating holds, canceling events, or re-querying availability as constraints evolve

Each of these steps is not hardcoded, but dynamically selected and executed via tool calls, with the agent continuously deciding what to do next based on context and intermediate results.

What this really means is that agentic software operates over an effectively unbounded and non-enumerable state space driven by probabilistic decision-making. In contrast, traditional software operates over a bounded and enumerable state space driven by deterministic execution.

This means we are no longer authorizing a fixed set of actions, but delegating decision-making authority to a system whose behavior cannot be fully specified ahead of time.

Now to add to this, there is a second, equally important challenge: identity and delegation.

Agent identity and delegation

Now that we have established that agents operate over an effectively unbounded and non-enumerable state space, a second implication follows. Agents begin to resemble entities with their own decision-making capability, rather than traditional software executing predefined logic.

This creates an interesting challenge in how we model agent identity.

In traditional systems, software identity is typically represented through static accounts, often referred to as service accounts, which are tightly scoped and explicitly controlled. These service accounts are what allow software running in production to access third-party resources such as APIs and databases.

With agents, this model begins to break down. Static service accounts are no longer sufficient, as agents do not operate under a single identity. They have their own system identity, but also act on behalf of users, dynamically exercising delegated permissions.

This distinction is subtle, but critical. Agents operate across contexts and make decisions over time while using user-level access.

As a result, authorization is no longer evaluated against a single identity. The system must account for both the agent’s identity and the end user’s identity, since the agent is making decisions using the user’s permissions.

The decision-maker and the permission-holder are no longer the same entity. The agent determines what to do, but does so using the user’s permissions.

Why traditional authorization models break for agents

To see why this breaks in practice, consider a simple scenario.

An agent is given access to a user’s calendar, email, and internal systems with the goal of “scheduling and coordinating meetings.” In a traditional system, the scope of actions would be tightly defined, with clear boundaries on what can and cannot be done.

In an agentic system, however, the agent is not just executing predefined actions. It is deciding which actions to take based on context, while operating under the user’s identity.

The challenge is not in any individual action. Reading emails, accessing calendars, sending invites, or modifying events are all valid operations within the scope of the task.

The problem emerges from how these actions are combined. Because the agent is continuously deciding what to do next, the sequence, timing, and composition of these actions are not fixed ahead of time. The effective scope of the system emerges during execution rather than being predefined.

In practice, this means an agent could:

• access data that was not originally intended to be part of the task

• take actions that exceed the user’s expectations

• chain together permissions across systems in ways that were never explicitly designed

The issue is not that any individual action is unauthorized, but that the combination of actions leads to outcomes that are difficult to anticipate or constrain.

Traditional authorization models assume that actions and execution paths can be defined ahead of time. Agentic systems violate this assumption.

We are no longer authorizing actions. We are authorizing systems that decide which actions to take.

Implications for authorization in an agentic world

This shift has significant implications for how we design authorization systems in an agentic world. It is no longer sufficient to define permissions as a static set of allowed actions tied to a single identity.

Instead, authorization must account for systems that act over time, make decisions dynamically, and operate under composed identities. This requires new models that can reason about intent, constrain behavior across sequences of actions, and provide stronger guarantees around how delegated authority is used.

The problem is no longer just controlling access, but governing how autonomous systems exercise it.

This is the problem space we are building for at Alter.