Every principal that touches your AI infrastructure needs a verified identity. Praesidia routes human users, backend applications, AI agents, and MCP servers through a single, policy-aware authentication layer that enforces the same session controls, MFA requirements, and audit logging regardless of who is on the other end. The result: one place to issue credentials, one place to revoke them, and one consistent audit trail across everything.
The problem with scattered credentials
Most organizations reach for the fastest option when wiring up a new integration: generate an API key, paste it into a config file, and ship it. That approach works for one service. It falls apart at ten, and it becomes ungovernable at fifty.
The deeper issue is not just the number of credentials. It is that each credential carries a different identity model. A user has an account with MFA, session expiry, and role assignments. An API key has none of that — it is a flat secret with binary access. An AI agent running autonomously has no account at all; it typically impersonates a service identity or inherits ambient credentials from the process it runs in.
When these principals coexist in the same system — and in an AI platform they always do — you end up with multiple authentication paths, multiple revocation mechanisms, and incomplete audit trails. A security incident requires stitching together logs from different systems just to answer the question: who did this, and when?
One identity model for every principal type
Praesidia defines four first-class principal types, each with an appropriate authentication mechanism:
Human users authenticate with email and password, social login, or a SAML/OIDC SSO provider connected to your existing identity directory. After a successful credential check, the platform evaluates whether MFA is required — either because the user enrolled voluntarily or because their organization's security policy mandates it. Only after that chain completes does the platform issue a session.
Applications (backend services, CI pipelines, internal tooling) authenticate using a client key and secret tied to a registered application record. The platform verifies the credential and issues a short-lived token scoped to the permissions the application was granted. No shared secrets, no long-lived bearer tokens left in environment files.
AI agents authenticate through the agent-to-agent (A2A) protocol using scoped credentials registered at agent provisioning time. Credentials are verified on every request; there is no session state for agents to carry between calls, which matches how stateless agent invocations actually work in practice. For a deeper look at why per-agent credentials matter, see AI Agent Identity: Why Agents Need Their Own Credentials.
MCP servers register as first-class entities with their own credentials and connection-level policies. Authentication establishes identity; the platform then applies guardrails to what content can flow through the connection and enforces rate limits and geographic restrictions independently of the credential check. See Registering and Governing MCP Servers for how this works in practice.
Why one front door beats per-integration keys
The practical difference is not architectural elegance — it is operational control.
When a credential needs to be revoked (an agent is decommissioned, an application is retired, a user leaves the organization), there is one place to do it. The revocation propagates immediately; there are no stale keys sitting in a config somewhere continuing to authenticate successfully.
Access review is also simpler. Instead of auditing a spreadsheet of API keys and guessing which service each belongs to, your team can enumerate principals — users, applications, agents, MCP servers — with their associated permissions, last-seen timestamps, and the organizational policies that govern them.
Audit logging is a first-class output of the authentication layer, not an afterthought. Every login, token issuance, sudo re-authentication, and session revocation generates an event with a consistent schema that can be queried or exported. You do not need to instrument each integration separately to get visibility. For how to act on those authentication events in real time, see Auth Monitoring and Login Security.
Sudo re-authentication for sensitive actions
One pattern worth calling out specifically is what Praesidia calls the sudo window. Certain mutations carry elevated risk relative to ordinary API calls — changes to authentication configuration and security settings that, if made through a hijacked session, would be significantly more damaging than reading data.
For these actions, the platform requires the user to re-prove their password before the change is accepted, regardless of how recently they authenticated. The re-authentication establishes a short-lived sudo window during which sensitive writes are permitted. Once the window expires, any further sensitive mutation requires another password confirmation.
This pattern is familiar from Unix-style systems and modern web applications alike. Its value in an AI control plane is that it limits the blast radius of a hijacked session: an attacker who steals a session token cannot make security-configuration changes without also knowing the account password.
SSO and the MFA-aware session path
Enterprise deployments typically want human users to authenticate through a central identity provider rather than managing passwords directly in Praesidia. The platform supports both OIDC and SAML 2.0 federation. When a user initiates SSO login, the platform redirects them to the configured identity provider, then processes the assertion or token returned from the callback.
Crucially, SSO login flows through the same MFA-aware path as password login. If the organization's security policy requires MFA, a successful SSO callback does not immediately establish a full session — the user is still routed through the MFA challenge step. This prevents SSO from being used as an MFA bypass, which is a common misconfiguration in platforms that treat SSO and local login as parallel, independent paths.
Session management and device visibility
Once authenticated, users can inspect all active sessions associated with their account: which devices, when each session was last used, and the ability to revoke any individual session remotely. This is standard practice for consumer applications; it is often missing from internal developer tools and AI platforms, where sessions are assumed to be trustworthy because the users are employees.
In a platform where AI agents run continuously on behalf of user accounts, session visibility matters more than usual. An operator who suspects an agent is misbehaving can revoke its delegated session without needing to rotate credentials for the entire service. For the security policies that govern session lifetime, IP restrictions, and MFA enforcement at the organization level, see Security Policies: Passwords, Sessions, and IP Restrictions.
Common questions
Does every AI agent need its own credentials, or can they share?
Agents should have dedicated credentials wherever operationally feasible. Shared credentials make revocation disruptive (revoking one compromised agent takes down all agents sharing the credential) and make audit logs ambiguous (you cannot distinguish which agent performed an action). Praesidia's agent registration model is designed to make per-agent credentials the path of least resistance, not an extra burden.
Can I connect an identity provider my team already uses?
Yes. Praesidia supports SAML 2.0 and OIDC federation, which covers the majority of enterprise identity providers. Users who authenticate through SSO still go through the same session lifecycle — MFA checks, sudo windows, and session revocation — as users who authenticate with passwords directly. See Single Sign-On for AI Agent Management: SAML and OIDC for configuration details.
What happens to agent credentials when an agent is decommissioned?
Revoking an agent's registration invalidates its credentials immediately. Any subsequent authentication attempt with those credentials is rejected. Because agents authenticate on every request rather than relying on long-lived sessions, the revocation takes effect without waiting for a token to expire.
Putting it together
The value of a unified identity model is not that it makes any single authentication flow more convenient. It is that it makes the entire system auditable, revocable, and policy-consistent. When the same enforcement layer — MFA requirements, session controls, permission scopes — applies to users, applications, agents, and MCP servers alike, you can reason about access across your AI infrastructure as a whole rather than reasoning about each integration in isolation.
Praesidia is designed around this principle: every principal that touches your AI infrastructure has an identity, every identity is governed by the same policy engine, and every action leaves a trace in the same audit log. You can read more about how this connects to broader access controls in Organizing Access with Teams and RBAC and Custom Roles for AI Operations.