- User / Agent
- Taylor Brooks
via Copilot
- Account
- Supplier Admins
AI agent authentication. Built for any software to sign in to any software.
Inbound, people connect AI clients over MCP OAuth, your backend uses a scoped API key, and agents get a session token that expires. Outbound, the Agent Execution Engine signs in to each system the way it requires and keeps the credential encrypted.
InHow callers reach StackOne
- MCP OAuth
People in AI clients, signed in with CIMD, DCR or a registered client.
- Session token
Agents and jobs. Allow and deny rules, 30 minutes by default.
- API key
Your backend. Scoped to one project.
- Account linking
Your customers connect their own systems in the Hub.
Checks the account and the action on every call.
- TLS 1.2 or later on every call out
- Credentials stored encrypted
- Your own key (BYOK) on Enterprise
- Never sent to an agent or AI client
OutHow the engine signs in
- OAuth 2.0 sign-in
197
- Client credentials
122
- API keys, tokens and Basic
335
- Session logins
7
- Signed requests
4
- Mutual TLS
3
- JWT key pairs
1
- Any remote MCP server DCR or your client, PKCE
Live connectors per method. A connector with several methods counts in each.
Inbound authentication. Four ways in to StackOne.
Pick the credential that fits the caller. Whichever one arrives, StackOne checks the account and the action on every call.
-
MCP OAuth
People in Claude, ChatGPT, Cursor and other AI clients
- Signs in
- Each person, with their StackOne login or your SSO, approving the accounts the client may use
- Lasts
- 1-hour access tokens under a 90-day grant, revocable at any time
- Reaches
- Only the accounts the person approved, with every call logged under their name
-
API keys
Your backend, SDKs and the StackOne CLI
- Signs in
- Your server, with HTTP Basic auth, inside one project
- Lasts
- Until you disable or delete it; last use is tracked
- Reaches
- Only the scopes you turn on. Credentials is off by default
-
Session tokens
Agents and scheduled jobs, each with its own short-lived key
- Signs in
- Whoever holds the token your server minted with its API key
- Lasts
- As long as you set: 30 minutes by default
- Reaches
- Only the accounts and tools its rules allow, for running actions only
-
Account linking
Your customers, connecting their own systems from inside your product
- Signs in
- Your customer's user, into their own system, through a session your server creates
- Lasts
- The session: 30 minutes by default. The linked account stays until it is removed
- Reaches
- Only that customer's accounts, kept apart by your customer ID
Session tokens. A short-lived key for every agent run.
Mint a session token for each agent run, customer request or job, limited to the accounts and tools it needs and expiring when you choose. Your API key never leaves your server.
# On your server: a 15-minute token that can only read deals
curl https://api.stackone.com/sessions \
-u "$STACKONE_API_KEY:" \
-H "Content-Type: application/json" \
-d '{
"tenant_id": "org_4f2a91c7",
"tenant_name": "Castell Health",
"expires_in": 900,
"scopes": {
"version": 1,
"permissions": [
{
"id": "read-deals",
"effect": "allow",
"resources": {
"accounts": ["<linked account id>"]
},
"actions": {
"tools": ["hubspot_list_deals", "hubspot_get_deal"]
}
}
]
}
}'
# The response includes "token".
# The agent sends it in a header:
# Authorization: Bearer <token>
# or, for clients that can't set headers, in the URL:
# https://api.stackone.com/mcp?token=<token>- Only the accounts you list
Name account IDs in its rules, and the token can't reach any other account.
- Expires on its own
Set expires_in in seconds. Leave it out and the token lasts 30 minutes.
- Only the tools you allow
Add allow and deny rules by account, connector, tool or operation, with wildcards. Once a token has rules, anything they do not allow is refused, and a deny always wins.
- Actions only
It runs actions and MCP tools. It cannot list accounts, mint tokens or change your project.
- In a header or the URL
Send it as a Bearer token, or put it in the MCP URL for clients that can't set headers. Treat a URL with a token in it like a password.
- Your API key stays put
Only your server holds it. A leaked token reaches only what its rules allow, and only until it expires.
Outbound authentication. However a system signs in, the Agent Execution Engine handles it.
Each connector carries its system's own sign-in method, and any remote MCP server you add becomes a connector too. The engine runs the sign-in on every call, so you never build an OAuth flow, a token store or a refresh job.
- OAuth 2.0 sign-in
A user approves access once. StackOne stores the tokens and uses PKCE where the system supports it.
- OAuth 2.0 client credentials
App-to-app access with no user in the loop.
- API keys, tokens and Basic auth
Entered once in the Hub and sent the way each system expects.
- Session logins
StackOne logs in as a service user and renews the session itself.
- Signed requests
Each request is signed with the stored key: AWS SigV4 or HMAC.
- Mutual TLS
A client certificate is presented on every connection.
-
ADP Workforce Now
- and 3 more
-
- JWT key pairs
Short-lived tokens signed with a stored private key (RS256).
- Any remote MCP server
Add any remote MCP server as a connector. StackOne signs in to it with OAuth, registering itself by dynamic client registration or using the OAuth client you enter, with PKCE on every sign-in.
- Our OAuth apps or yours
Start with StackOne's, or register your own for your branding and your own rate limits.
- Refreshed before expiry
Tokens renew at 80% of their lifetime, with retries. If renewal keeps failing, the account asks to be re-linked.
- Tested when linked
Most connectors run a test call before an account is saved, so bad credentials fail at the Hub.
- Encrypted at rest
Credentials are stored encrypted, and the engine uses them to sign each request to the system.
Security review. Credentials your security team can sign off on.
"As a company rooted in security assurance, we needed a partner sharing our priorities. StackOne's approach gave us confidence to scale without compromise."
SOC 2 Type II
Request the report, and review subprocessors and security information, in our trust center.
Visit the trust centerFAQ. Questions about agent authentication
Give your agents access, not passwords.
Talk through how your people, agents and customers will authenticate.