Scope tools, not tokens [Coming soon]

Services like GitHub already let you scope a token — but those scopes are built for everyone, so they stop at a level far broader than one agent’s job. Store your tokens in one secure place, expose each API as a set of tools, and write your own policy: grant every agent only the tools — and the argument values — its job needs. The agent calls the tools; it never sees the token.

Plenty of services let you scope an API token — GitHub has fine-grained tokens, others have their own. But those scopes are designed for everyone, to cover every use case, so they’re coarse: they stop at whole resources or endpoints, rarely at individual arguments, and the narrowest token you can mint is usually still far broader than the one small thing you want an agent to do. Hand it over anyway and the agent can do everything that token can — and your secret now lives wherever the agent runs.

What you’ll achieve

Your tokens kept in one secure place — not copied into agents, not scattered across machines.
Each agent granted only the tools its job needs, and only the argument values you allow.
Agents that call capabilities without ever holding, seeing, or being able to leak the token.
One place to grant, tighten, or revoke any agent’s access — without re-keying the service.

Scope tools, not tokens

Even a scoped token is blunt — its permissions are the provider’s, written to fit everyone. A tool is precise, and the policy around it is yours. Instead of giving an agent the key, you expose the API behind ours.network as tools and write your own rules per agent: which tools it gets, and which argument values are in bounds. “Read tickets” without “close account.” “Open a pull request” without “delete the repo.” “Charge a card, up to $50” without “refund anything.” These are distinctions a provider’s scopes usually can’t even express — yours to draw, exactly where your situation needs them.

How it works

Your tokens live in a secure store the agent can’t reach. ours.network presents the API to the agent as tools, and a per-agent policy decides which tools appear and which arguments are in bounds. When the agent calls a tool, ours.network checks it against the policy, makes the real API call with your stored token, and returns only what the policy permits. The agent works entirely in terms of tools — the token never crosses the channel.

You stay in control

The token stays in the secure store, at the application layer — an agent never holds it, and can’t leak what it can’t see.
Access is defined per agent and tied to a verifiable ours.network identity — you grant by who is connecting, not by handing out a copyable secret.
Scope is deterministic and argument-aware — more granular than the access the service itself offers.
It layers on top of the service’s own permissions: refine and narrow what it offers, or add scoping where it offers none — always within what your token can actually do, never beyond it.
Change or revoke any agent’s tools in one place, instantly, without rotating the underlying key.

What it looks like

A support agent that can read tickets but never close an account.
A finance agent that can issue refunds up to a set limit — and nothing larger.
A research agent with read-only access to a data API.
A deploy agent that can ship to staging, but never to production.