Last updated: July 23, 2026
Governance starts at the workspace boundary
Foundry projects hold models and agents; Kimss workspaces hold policy—who belongs, what they may run, how much they may spend, and which Foundry project backs their traffic.
Azure AI Foundry excels at agent authoring and model deployment. What it does not automatically provide is a SaaS-style multi-tenant product layer: per-customer isolation, productized RBAC, and finance-friendly usage units. Kimss fills that gap for ISVs, internal platform teams, and enterprises shipping AI into many codebases.
Each workspace maps to authenticated members, API keys, agent definitions, file storage, and credit pools. Routing logic selects the appropriate Foundry project or shared infrastructure shard so operators are not maintaining one Foundry project per end customer by hand.
Identity, keys, and least privilege
Interactive users sign in with Microsoft Entra ID; services use scoped API keys. RBAC roles inside a workspace constrain who can create agents, rotate keys, or view usage—reducing the blast radius of a leaked credential.
A common anti-pattern is embedding a single Foundry key in every microservice. Kimss replaces that with workspace-scoped keys and bearer tokens whose permissions are enforced server-side on every /v1 call. Combined with Entra SSO for Studio and admin flows, identity stays in the directory your security team already operates.
For enterprise buyers, SCIM-oriented provisioning hooks help align Kimss workspace membership with Entra groups. Detailed RBAC documentation appears in /docs/architecture and the public API docs.
Usage visibility finance can reconcile
Kimss Credits translate model consumption into a normalized ledger: allocations, usage, top-ups, overage, and adjustments—so engineering attribution and finance reconciliation share one vocabulary.
Raw token counts from disparate models are difficult to budget. Kimss Credits are a product layer on top of Azure metering: they do not replace your Azure invoice, but they let teams set monthly pools and group budgets that match how the business thinks about capacity.
Append-only billing records support investigations when a team exceeds forecast. Usage aggregates tie requests to tenants, workspaces, agents, and billing keys—useful for chargeback and for proving governance in reviews.
Audit-friendly execution without blocking builders
Governance should enable shipping: streaming agent runs, tool calls, and vector retrieval continue through the universal gateway while metadata for compliance is captured consistently at the control plane.
Builders keep using POST /v1/agents/run and the Python SDK. Operators configure policies once per workspace. When APIM gateway logging is enabled in an environment, GatewayLogs in Log Analytics can supplement Kimss-side attribution for Article 12-style audit discussions—verify your specific deployment path in architecture docs.
Legacy /assistant_* endpoints remain for compatibility, but new integrations should adopt /v1 to inherit current governance behavior.
Implementation patterns for Azure AI Foundry governance
Teams succeed with Azure AI Foundry governance when they treat Kimss as the integration boundary: applications never hold Foundry secrets, every call includes workspace context, and operators review credit trends before expanding model access.
Start in a non-production workspace. Wire governed agent runs against POST /v1/agents/run or POST /v1/models/completions using X-Kimss-Key or a bearer token. Validate streaming, tool invocation, and error paths your production clients rely on.
Document which Entra groups map to which workspace roles. Align workspace RBAC with monthly credit pools so finance sees predictable units rather than surprise token spikes on the Azure invoice.
Publish an internal integration checklist: required headers, workspace identifiers, approved models, and escalation paths when credits approach exhaustion.
Use /docs/architecture to confirm whether your tenant uses direct Foundry routing or an optional APIM path. Do not enable gateway-only modes in production until end-to-end verification passes in your environment.
When Foundry project routing spans multiple internal products, give each product its own API key or sub-workspace budget so attribution stays legible in usage aggregates and billing ledgers.
Common mistakes when rolling out Azure AI Foundry governance
The costliest errors are shared Foundry keys in microservices, skipping workspace headers on multi-tenant keys, and migrating user-facing flows before server-side credit enforcement is tested.
Embedding one project key in every service bypasses Kimss RBAC and makes revocation a company-wide fire drill. Issue workspace-scoped keys per service or per environment instead.
Assuming legacy /assistant_* behavior matches /v1 governance causes silent gaps in metering or identity. Inventory clients with /assistants-to-v1-migration and retire legacy paths deliberately.
Treating Kimss Credits as cosmetic reporting rather than enforced pools invites overrun. Configure exhaustion policies in staging and confirm blocked requests behave as product management expects.
Publishing internal runbooks that reference production Swagger instead of /docs/api_docs creates integration drift. The public API reference is the supported contract for external integrators.
Skipping staging verification for streaming and tool calls leads to production surprises. Exercise the same client libraries and timeouts you expect under peak load.
Next steps for Azure AI Foundry governance
Create a workspace, read /why-kimss for positioning, follow /python-sdk-mcp-quickstart for code, and engage /enterprise when contractual isolation, capacity, or onboarding differ from self-serve plans.
Self-serve teams typically progress: signup, first agent run via SDK, credit pool configuration, Entra SSO for Studio users, then wider rollout to internal consumers or customer tenants.
For Azure AI Foundry governance, schedule a monthly review of usage aggregates, ledger entries, and agent inventory. Remove unused keys, archive obsolete agents, and adjust group budgets after major launches.
Customer-facing ISVs should pair Kimss workspace design with /multi-tenant-ai-security and /ai-rbac-and-identity so each end customer receives isolated agents, files, and usage rows.
Track product changes at /changelog and deeper narratives at /insights so your platform team does not miss SDK or API shifts that affect deployed clients.
Documentation and honest scope
Kimss documents the supported integration surface at /docs/api_docs and system design at /docs/architecture—avoid assuming every internal admin route is available in the public SDK or MCP server.
Platform engineers should bookmark /docs/api_docs as the contract for external integrators. When product management requests a feature, verify whether it exists on /v1, requires an admin API, or needs net-new development before committing customer timelines.
Kimss Credits, Entra SSO, workspace RBAC, and PostgreSQL isolation are first-class product capabilities—not marketing adjectives. Validate them in your tenant with test workspaces and realistic agent workloads rather than slide-deck assumptions.
Optional Azure API Management integration remains documented as an advanced path. Production enablement should follow your organization's verification checklist for gateway telemetry and routing parity with direct Foundry execution.
When questions fall outside public documentation, enterprise customers can reach Kimss via /enterprise. Self-serve builders can use in-product support after signup.
Verify before you scale
Treat Kimss as production infrastructure: validate identity, credits, and routing in a staging workspace, read /docs/api_docs for the supported contract, and expand pools only after usage patterns are understood.
Platform teams should run monthly reviews of workspace keys, agent inventory, and ledger entries. Remove unused credentials, archive obsolete agents, and align group budgets with teams that actually ship. Pair Kimss attribution with Azure Cost Management for infrastructure truth—the credits layer governs product behavior; Azure still bills underlying Foundry consumption.
When you need help beyond public documentation, self-serve builders use in-product support after signup; enterprise buyers start at /enterprise for onboarding, capacity, and contractual questions. Product changes publish at /changelog so integrators can track SDK and API shifts over time.