When you run an AI agent platform for multiple tenants, a single global security policy is almost always wrong. A financial services organization has different tolerance for session length than an internal developer tool team. A healthcare customer may be obligated by contract to enforce MFA for every user. A team operating in a sensitive network perimeter may need to restrict access by IP range. The answer is per-organization security policies: each tenant configures the controls that match its risk profile, and the platform enforces them at every relevant point.

Praesidia gives every organization administrator a policy surface that covers five major control areas: password rules, session lifetime, account lockout, MFA mandates, and IP access restrictions. These are not advisory settings — they are enforced server-side on every authentication and login event. For an overview of how these controls fit into the broader identity model, see multi-tenant organizations and membership and RBAC and custom roles for AI operations.

Why Per-Org Policy Beats Global Defaults

A global security policy is a compromise between the most permissive and most restrictive tenant you serve. Global minimum password length of 8 is too weak for some customers and imposes no burden on others. A global session timeout of 24 hours is a serious risk for a high-sensitivity workflow and irrelevant friction for a long-running agent pipeline.

Per-org policy lets each organization administrator configure controls appropriate to their team's risk level and operational norms — without requiring the platform operator to pick a single setting that serves everyone poorly. Tenants inherit secure defaults and can tighten them; they cannot weaken controls below those defaults.

Password Complexity and History

Password complexity rules exist because humans choose predictable passwords when given a free choice. The policy controls available here cover the most widely recognized password hygiene requirements without over-specifying to the point of being counterproductive.

An organization administrator can configure password complexity requirements across the standard dimensions — length, character class requirements — to cover the practical surface of dictionary and credential-stuffing attacks without demanding policies so strict that users simply route around them with predictable patterns.

Beyond initial password quality, the policy surface includes a password history count: the platform rejects a new password if it matches any of the last N passwords the user has set. This prevents the common rotation-evasion pattern where users cycle through a small pool of variations. The history count is configurable per organization.

All of these controls are enforced at the point of password change and at account creation. A password that does not meet policy is rejected before it is stored, not retroactively invalidated — which means users get immediate feedback and the enforcement is unambiguous.

Session Timeouts

Session length is a direct trade-off between user convenience and the exposure window when a credential is compromised. A long session is convenient for legitimate users and a long opportunity for an attacker holding a stolen token.

Each organization can specify a session timeout that controls how long an issued session credential remains valid. The configurable range is bounded — short enough to limit exposure, long enough that legitimate users are not forced to re-authenticate mid-workflow. When a user's session exceeds the organization's timeout, the next authenticated request fails, forcing re-login.

Because AI control planes often involve automated agents that hold their own credentials, human session timeout and agent token lifetime are managed separately. The per-org session timeout applies to human user sessions authenticated through the normal login flow. Agent credentials follow a separate path with their own scoping and expiry.

Operators who want to tighten the session window for privileged roles — administrators configuring security settings, for example — can layer on MFA step-up requirements for sensitive operations on top of the session timeout. The two controls are complementary: the session timeout limits the overall window, and step-up MFA adds a checkpoint at the moment of a high-risk action.

Account Lockout

Account lockout prevents brute-force and credential-stuffing attacks by temporarily locking an account after a configured number of failed login attempts. The policy surface lets an organization administrator set both the threshold (how many consecutive failures trigger a lockout) and the duration (how long the account remains locked).

Choosing these values involves a real trade-off between protection against automated attacks and the risk of denial-of-service against specific users if the threshold is set aggressively. The defaults balance these concerns. Organizations can tune within the available range.

After the lockout duration expires, the account automatically unlocks. Administrators can also manually unlock accounts through the admin interface, which is important for support scenarios where a user has legitimately triggered a lockout and needs immediate access restored.

Mandatory MFA

The organization-level MFA mandate forces every user in the organization to complete MFA enrollment before they can proceed with authenticated actions. Unlike per-user MFA, which depends on individual user choices, the org-level mandate is enforced regardless of individual user settings.

When the mandate is enabled, users who have not completed MFA enrollment are redirected to the enrollment flow on their next login. They cannot bypass this step or skip enrollment. Users who have already enrolled are not affected — their existing enrolled factors continue to work normally.

This control is particularly useful for organizations with compliance requirements that specify MFA for all users with access to regulated systems. It removes the operational burden of monitoring individual enrollment status and eliminates the risk of a user account operating without MFA because a user opted out.

IP Access Restrictions

IP restrictions add a network-layer access control to the authentication surface. An organization administrator can define a list of allowed IP ranges; any login or API call originating from an IP outside those ranges is rejected before authentication proceeds.

This is most useful for organizations that operate from a known network perimeter — an office network, a VPN range, or a specific cloud egress range — and want to ensure that even valid credentials cannot be used from an unexpected location. A stolen credential that cannot be used from an attacker's infrastructure is significantly less valuable.

IP restrictions operate at the organization level and apply to all users. They are additive with authentication: a user must both pass IP validation and authenticate successfully. Controls are evaluated on every request.

Adding an IP restriction creates an operational consideration: administrators should ensure changes to the allowed range are made before the previous range is removed, and that an emergency access path exists. For how IP restrictions interact with federated login flows, see single sign-on for AI agent management: SAML and OIDC.

Sudo Mode for Policy Changes

Changing the security policy is itself a high-privilege action. Praesidia requires sudo mode — a step-up authentication challenge — before an administrator can modify the security policy, add or remove IP restrictions, or update the SSO configuration. This is the same principle applied in MFA for AI control planes, where step-up authentication protects sensitive operations independently of session age.

This matters because policy changes have immediate, broad effects. Enabling a mandatory MFA requirement affects every user in the organization. Removing an IP restriction could open access from previously blocked ranges. Requiring re-authentication at the moment of change means a policy update cannot happen silently from a compromised session.

Sudo mode challenges are time-limited. The elevation is recorded in the audit log, creating a clear record of who changed which policy setting and when.

How Praesidia enforces policies end to end

These are not settings that get stored and occasionally consulted. Praesidia resolves the relevant organization's policy at the point of each login, password change, and session validation:

  • Password rules are evaluated when a user sets or changes their password.
  • Password history is checked at the same point against the stored history for that user.
  • Session timeout controls the lifetime of each issued session credential, evaluated per organization.
  • Lockout threshold and duration are evaluated on each failed login attempt and resolved per organization.
  • MFA mandate is evaluated at session establishment, before the user can proceed.
  • IP restrictions are evaluated on each incoming request against the calling IP.

Because each of these evaluations reads the organization's current policy at runtime, changes take effect immediately for subsequent authentications — there is no cache to flush or restart required.

Common questions

Can I set different policies for different user roles within an organization? The current policy surface operates at the organization level — settings apply to all users in that organization. Layering role-specific controls on top of the base policy is handled through other mechanisms: administrators can require step-up authentication for specific high-privilege actions, and role-based access controls determine which actions users can take at all. The organization-level policy establishes the floor for everyone.

What happens if I tighten the session timeout while users are logged in? The new timeout takes effect for sessions issued after the policy change. If you need to invalidate all existing sessions immediately, that requires an explicit session revocation action rather than a timeout change.

How do IP restrictions interact with agents using API credentials? IP restrictions apply to the authentication surface for human user sessions. Agent credentials are governed by their own connection and trust policies rather than by the human user IP policy. This separation is intentional: agents often run in infrastructure that does not match a human user's IP range, and a single shared IP policy would create operational problems for automated workloads.

Where do these controls fit in a broader compliance program? Per-org security policies address the authentication hardening layer that auditors typically evaluate first. For compliance frameworks that require MFA, session management, and access logging, these settings provide the enforceable controls, while the audit trail records every authentication event and policy change. For more on how the audit trail supports compliance, see audit trails that hold up.

For more on how authentication and access control fit together across Praesidia's identity model, see zero trust for AI agents and how to audit AI agent activity. For how SCIM provisioning keeps access current as users join and leave, see automating user lifecycle with SCIM 2.0.