When an external system needs to call your AI agents programmatically, registering it as a named Application gives you scoped credentials, an explicit list of agents it may reach, and a full lifecycle from issuance to revocation. Instead of tracking which service has which raw API key, you manage each integration as a discrete identity — one you can audit, suspend, or rotate independently without touching any other caller.
The cost of unmodeled API consumers
In most early-stage AI deployments, programmatic access control is an afterthought. A developer generates one key for the whole platform, shares it across three services, and moves on. Six months later nobody remembers which system has it, rotating it breaks something unexpected, and the audit log shows every request as "the API key" with no way to distinguish the customer portal from the internal batch job.
This compounds when agents are involved. An agent that processes customer data has a different risk profile from one that generates marketing copy. If a single credential can reach both, a compromised or misconfigured integration has a larger blast radius than it should. The fix is not a tighter rotation schedule; it is modeling each caller as a distinct, named entity with a bounded set of permissions from the start.
Applications as first-class identities
In Praesidia, every external integration registers as an Application: a backend service, CI pipeline, internal tool, partner webhook consumer, or any other system that needs programmatic access. An Application is not a shortcut to an API key — it is a managed identity with the same governance properties as a human user account.
When you register an Application, the platform issues a scoped API key and displays it exactly once. Only a short prefix for identification and a cryptographic hash are retained after that moment. This mirrors the pattern used by services like GitHub and Stripe: a stolen credential store is far less useful when it contains only hashes, and the one-time display creates a forcing function to store the key securely at creation time rather than retrieving it from a dashboard that could itself be compromised. For the full picture of how machine credentials compare with short-lived OAuth tokens, see MCP Server Authentication: OAuth 2.1 vs API Keys.
The Application record then carries everything you need to reason about the integration: its name and description, who registered it, when it was last used, how many requests it has made, and what it is permitted to do.
Scopes: bounding what an integration can request
Not every integration needs the same access. A read-only reporting tool does not need to invoke agent tasks. A deployment pipeline that triggers workflow runs does not need access to billing records. Applications declare their scopes at registration time, and those scopes travel with every authenticated request.
Scopes let you enforce least-privilege at the consumer layer without modifying the underlying agents or workflows those consumers call. An integration that asks for a capability outside its declared scopes is rejected at the authentication boundary. Looking at an Application record tells you unambiguously what that consumer is authorized to request — without tracing through the implementation to reconstruct it.
Per-agent access: deny by default
Beyond scopes, each Application carries an explicit agent access list. The default mode is deny-all: a newly registered Application has no implicit permission to call any agent, even agents that exist within the same organization. Access to each agent must be granted deliberately.
This posture matters because your agent fleet will grow over time. A new agent added next month should not be automatically reachable by every Application registered today. Deny-by-default means new agents are protected until access is intentionally extended — not exposed until someone remembers to restrict them.
Granting and revoking per-agent access is a first-class operation: a named action on the Application record, logged to the audit trail, reversible at any time through the management console or the API.
Key lifecycle: rotation, suspension, and revocation
Application keys go through a managed lifecycle rather than existing indefinitely until manually deleted.
Rotation is a first-class operation. When a key needs replacing — because an engineer left, because it was accidentally logged, or as a periodic hygiene measure — you regenerate it from the Application record. The platform invalidates the old key immediately and returns the new one for a single display. The Application's scopes, agent access list, and history are preserved, so rotation is a minimal-disruption operation affecting only the one integration.
Suspension pauses an Application without deleting it. Subsequent authentication attempts are rejected, but the configuration and audit history remain intact. This is the right tool when you are investigating anomalous traffic and want to stop it immediately while preserving the evidence you will need to understand it.
Revocation permanently disables an Application. Its key is rejected on all subsequent requests, and the revocation is recorded with a timestamp. Revocation is appropriate when an integration is decommissioned or a key is confirmed compromised and rotation is not sufficient.
Applications also support an optional expiry date. For short-lived integrations — a proof-of-concept, temporary partner access — you set the key to expire automatically rather than relying on someone to clean it up. After expiry, the key is rejected even if it has not been explicitly revoked.
Rate limits, visibility, and dormancy detection
High-volume or poorly-behaved integrations should not crowd out other consumers or drive unexpected cost. Per-Application rate limits let you set a ceiling for each integration based on what it legitimately needs, independent of any organization-wide or agent-level limits. An integration that exceeds its limit receives a rejection; other Applications on the same organization are unaffected. This makes it straightforward to give a batch pipeline a generous sustained rate limit while holding an interactive internal tool to a lower ceiling, without any of those limits interfering with each other.
Every Application request is also recorded against the Application record. Last-used timestamps make it easy to identify dormant integrations during an access review — a key that has not been seen in thirty days is a candidate for suspension or revocation. Request counts give you the volume picture: the difference between an integration making a handful of calls a day and one generating thousands is immediately visible without querying logs. For deeper breakdowns of cost and token consumption by integration, per-connection tracking carries the data further — see Tracking Per-Connection AI Usage and Cost for how these surfaces compose.
How Applications fit the broader identity model
Applications are one of four principal types the platform authenticates, alongside human users, AI agents, and MCP servers. A credential is resolved by the authentication layer to a structured identity: the Application's ID, the organization it belongs to, and the scopes it holds. Downstream authorization — which agents the Application can reach, which operations it can perform — is made against that identity, not against a raw key.
This means Applications are not a separate authentication pathway bolted on the side. They are first-class principals in the same access-control model, subject to the same organization scoping and feature gating that governs every other caller. An Application registered in one organization cannot, by construction, reach data or agents belonging to another. For a broader picture of how agent identities, human users, and machine credentials fit together, see How to Authenticate AI Agents.
Common questions
How is an Application different from a personal API token?
A personal token carries the identity and permissions of the human who created it — it changes when that person's access changes, and it is tied to an individual account. An Application is an independent principal representing a named integration. It has its own scopes, its own agent access list, and its own lifecycle. It is not tied to any individual user, so it survives personnel changes and can be managed as infrastructure.
What is the fastest way to stop a compromised Application key?
Suspend or revoke the Application from the management console or the API. Both take effect at the next authentication attempt, which for stateless API key validation is effectively immediate. Suspension preserves the Application record and audit history for investigation; revocation permanently disables it. Because each integration has its own Application, the action is surgical — no other integrations are affected.
Can I limit an Application to a single agent?
Yes. Grant access to exactly the one agent that integration needs. The deny-by-default access mode means every other agent in the organization is unreachable from that Application regardless of what it requests. You can add or remove agents from the allow-list at any time without issuing a new key.
The principle behind Praesidia's Applications model is that every programmatic caller deserves the same governance you apply to human users: a named identity, bounded access, an auditable history, and a clean revocation path. Raw API keys issued outside this model become liabilities over time because they carry no context that would let you manage them as a fleet.
By registering each integration as an Application, you gain the operational clarity to answer the questions that matter: who is calling, what can they reach, when did they last call, and how do you stop them when you need to. For guidance on how scoped credentials fit within a broader least-privilege posture, see How to Implement Least Privilege for AI Agents.