Agent identity: who may run what

Humans versus services

Interactive Studio and admin flows use Microsoft Entra ID. Automation and product backends use API keys or bearer tokens whose permissions Kimss enforces on each /v1 call.

Collapsing both into one long-lived Foundry secret is the root identity anti-pattern. Rotate keys per environment, map Entra groups to workspace roles, and avoid embedding project keys in mobile clients.

Enterprise buyers can align membership with directory groups using SCIM-oriented provisioning hooks—details in /docs/identity_sso and /ai-rbac-and-identity.

RBAC inside the workspace

Roles constrain who can create agents, rotate keys, view usage, or administer billing—reducing insider and accidental privilege risk.

Least privilege is not only an Azure IAM concern. Product RBAC must exist at the SaaS layer when many internal teams share one Kimss deployment. Document role mappings in your internal runbooks alongside credit pool owners.

Agents as inventory, not anonymous scripts

Treat agent definitions as owned assets with change history and environment promotion—Kimss holds definitions; Foundry runs materialized copies.

Portable definitions help answer identity questions during incidents: which version ran, in which workspace, under which key. See /docs/environments_and_agent_portability and /docs/creating_agents.

Implementation checklist

Wire Entra, assign roles, issue environment-scoped keys, verify denials in staging, then expand.

• Enable Entra SSO for operators.
• Map groups to workspace roles.
• Create separate keys for CI, staging, and production services.
• Deny tests: wrong workspace key must fail.
• Review membership and unused keys monthly.

Frequently asked questions