Every account management surface in an AI platform is a potential entry point for an attacker. The question is not whether to expose account controls, but how to divide them: what can a user change about their own account, and what requires an administrator? Getting that boundary wrong in either direction creates risk — over-permissioned users can silently elevate themselves, and under-powered users create admin bottlenecks that erode security habits.
A well-designed platform draws that boundary clearly: self-service operations are scoped exclusively to the authenticated user's own identity, while org-admin actions require explicit role authorization and are always scoped to the organization the admin belongs to. Neither surface can reach data outside its intended scope.
Why the self-service boundary matters
Account management at scale almost always drifts toward one of two failure modes. In the first, administrators handle everything — password resets, profile updates, notification changes — which creates a support bottleneck and means sensitive credentials sit in help-desk tickets longer than they should. In the second, any authenticated user can modify any other user's attributes, which is a straightforward horizontal privilege escalation vector.
A well-designed self-service model eliminates both problems. Users own their own profile, their own credentials, and their own preferences. They cannot reference another user's identifier in a self-service call; the platform ignores any such attempt and binds the operation to the authenticated session. Administrators get a separate surface, separately guarded, that operates within their organization's boundary.
This is the same principle behind Unix's design of letting users change their own password with passwd while only root can modify /etc/shadow directly — least privilege applied to identity management.
What users can manage themselves
On the self-service side, each authenticated user can update their own display name, contact details, and similar profile fields. Notification preferences — which event categories trigger emails or in-app alerts — are also self-managed, reducing the noise of irrelevant notifications without requiring admin involvement.
Personal API keys deserve special attention. Keys are the credential most likely to be long-lived, shared in configuration files, and forgotten. A self-service API key surface lets users generate keys with defined scopes and expiry dates, list what they have created, rotate a key when it has been exposed, and delete keys that are no longer needed. Creation and rotation are rate-limited and require the user to confirm their session is still valid — a step-up check that prevents a hijacked browser session from quietly minting new credentials.
Data portability is also user-controlled. Any user can request an export of their own account data, covering the profile fields, preferences, and activity associated with their identity. This satisfies the access and portability requirements of data protection regulations without requiring an admin to manually compile and transmit a report.
Finally, account deletion is a self-service action, but a deliberately friction-ful one. The user must confirm with their current password. All active sessions are revoked immediately. The operation is rate-limited to prevent automated abuse. The sequence mirrors the erasure path required by data protection frameworks: the user's identity and associated personal data are removed from the live dataset, with the cascade handled automatically rather than leaving orphaned records.
What administrators control
The org-admin surface covers the membership of the organization as a whole. Administrators can list all members, view individual member profiles, and update member attributes — but only within their own organization. The platform enforces this structurally: a request carrying a valid admin token cannot be redirected to a user in a different organization by manipulating a URL parameter.
Team membership is managed here too. An admin can assign a member to a team or remove them, which in turn affects what workflows, agents, and features that person can access. The teams and membership system is described in more detail in organizing access with teams, but the key point for account hygiene is that de-assigning someone from a team revokes their team-scoped access immediately.
The admin surface is read-heavy for most organizations. Day-to-day operations are user-driven; admins spend most of their time on onboarding (adding new members to the right teams) and offboarding (which is typically handled through SCIM deprovision rather than manual deletion). The manual admin controls exist for edge cases and smaller teams that have not yet automated provisioning. For how SCIM-based provisioning handles the automated path, see automating user lifecycle with SCIM 2.0.
API keys as a security surface
Personal API keys warrant a closer look because they are the most operationally sensitive credential a regular user manages. Unlike session tokens, which expire quickly, API keys are designed to be long-lived and embedded in automation. That design makes them useful and dangerous in equal measure.
A few practices reduce the risk significantly. First, scope every key to the minimum set of permissions it needs — a principle covered in depth in how to implement least privilege for AI agents. A key used by a monitoring script to read agent status does not need permission to create workflows or delete accounts. Narrow scopes limit the blast radius if a key is compromised.
Second, set expiry dates. A key with no expiry is a credential that will eventually be forgotten in a configuration file, a dotfile, or a Docker image layer. Expiry forces periodic rotation and creates natural checkpoints to audit whether each key is still needed.
Third, treat key rotation as routine maintenance, not an emergency response. Keys rotate cleanly — the old key remains valid until the rotation completes and the new secret is safely stored. Rotation should be boring.
The audit log records every key creation, rotation, and deletion event, so there is always a clear record of which keys existed and when they changed.
Sudo-mode and step-up authentication
Several self-service operations are intentionally more demanding than a standard authenticated request. Creating an API key, rotating an existing key, and deleting the account all require the user to confirm their identity within the current session — typically by re-entering their password — before the operation proceeds.
This pattern, sometimes called sudo mode after the Unix concept, limits the window of exposure for a hijacked session. If an attacker gains access to a logged-in browser session through XSS or a stolen cookie, they can browse the application. They cannot, however, issue new credentials or delete the account without knowing the current password. The most destructive self-service operations are gated behind a second factor of knowledge.
Sudo mode also has a time bound. If a user confirms their identity and then steps away, the elevated permission window expires. Subsequent sensitive operations require re-confirmation. This is the same model used by cloud consoles for operations like IAM key creation — the experience may feel slightly inconvenient for users, but the security trade-off is well understood.
Admin controls and the principle of least privilege
The administrative surface follows the same least-privilege logic. Not every org member gets admin rights. The platform distinguishes between owners, who have full administrative capability including billing and org configuration, and members, who have standard access. Only owners can update another member's attributes or manage team assignments.
This matters because role creep is one of the most common sources of privilege escalation in enterprise software. When "admin" is a binary flag applied generously to avoid support requests, it eventually means nothing. Granular roles, enforced at the authorization layer, ensure that the user who can approve an invoice is not automatically the user who can rotate another person's credentials.
For organizations with more complex access requirements, the roles and permissions system described in RBAC and custom roles for AI operations extends this further — custom roles can be built from fine-grained permission sets, and those roles can be scoped to teams rather than applied org-wide.
Common questions
Can an admin view another user's API keys or credentials?
No. The API key secret is only exposed once, at creation time, and is stored as a one-way hash. Administrators can see that a key exists — its name, prefix, scope, and last-used timestamp — but cannot recover the secret. If a key needs to be revoked, an admin can delete it; only the key owner can rotate it (which generates a new secret).
What happens to a user's API keys when their account is deleted?
All personal API keys are revoked immediately as part of the account deletion sequence. Any automation using those keys will begin to receive authentication errors. Organizations relying on keys tied to individual accounts should migrate to service account keys or rotate before offboarding.
Can a user export data for compliance without admin involvement?
Yes. The self-service data export returns the authenticated user's own profile data and preferences without requiring an admin to approve or mediate the request. This is designed to satisfy data subject access requests under data protection regulations without creating an admin bottleneck for routine compliance operations.
How does multi-factor authentication interact with the self-service surface?
MFA protects the initial session, but step-up (sudo) mode is a separate layer that applies specifically to credential-creating and credential-destroying operations. Even with MFA already satisfied at login, operations like API key creation or account deletion require a re-confirmation step within the current session. This means a session legitimately established hours ago — and potentially since left unattended — cannot be used to silently issue new credentials. For how MFA is configured on an AI control plane, see MFA for AI control planes: TOTP and backup codes.
Keeping the attack surface small
Account management is where security posture becomes concrete. Binding self-service routes strictly to the authenticated session, requiring step-up confirmation for credential operations, and scoping all admin actions to the authenticated organization keeps the attack surface predictable. There are no hidden parameters to manipulate, no admin overrides accessible to regular users, and no way for a valid but compromised session to silently mint new credentials.
The result is an account management model that is usable enough that users will actually keep their own credentials current, and locked down enough that a compromised session does not automatically become a full account takeover.