Educational · Security

AI agent security for enterprise platforms

Agent security is more than prompt injection headlines. It is key hygiene, tenant isolation, tool authorization, spend abuse prevention, and evidence for auditors. Kimss hardens the product edge while Azure AI Foundry executes agents.

Last updated: July 24, 2026

Threat model for productized agents

Assume leaked service keys, cross-tenant curiosity, abusive tool loops, and prompt tampering. Design so each failure is contained to a workspace and reversible.

Shared Foundry project keys in microservices maximize blast radius. Kimss workspace-scoped keys and server-side RBAC reduce that radius. Credit exhaustion policies limit financial damage from runaway loops.

Tool calls that hit internal APIs need the same scrutiny as any service principal. Pair agent roles with least privilege in your own systems—not only in Kimss.

Controls that matter in production

Identity, isolation, metering, and audit metadata form the minimum viable agent security stack for multi-tenant products.

  • Entra SSO for humans; scoped API keys for services.
  • PostgreSQL workspace isolation for agents, files, and usage rows.
  • Kimss Credits with soft alerts and hard caps.
  • Attribution of runs to workspace, agent, and key.
  • Optional APIM gateway logs to Log Analytics when verified end-to-end.

How Kimss maps to the controls

Kimss productizes the control plane so application teams do not reinvent tenancy for every agent launch.

Read /multi-tenant-ai-security for isolation patterns, /docs/security_architecture for system design, and /docs/trust_safety for guardrail posture. Formal attestations for procurement are handled under NDA via /enterprise.

Builders should prefer /v1 over legacy assistant endpoints so metering and identity behavior stay current—see /assistants-to-v1-migration.

Operational practices

Run tabletop exercises on key compromise and pool exhaustion; rotate credentials; archive unused agents monthly.

Security reviews should include staging tests that attempt cross-workspace access with the wrong key and confirm denial. Treat credit exhaustion behavior as a security control against resource abuse, not only a finance feature.

Frequently asked questions

Does Kimss prevent prompt injection?

Kimss focuses on platform controls (keys, tenancy, credits, audit). Application-level prompt defenses and Content Safety policies remain part of your Azure and app design.

Where is the security architecture documented?

/docs/security_architecture and /docs/security_compliance.

How do we limit tool blast radius?

Scope tools in your backend, use least-privilege service identities, and keep Kimss keys workspace-scoped per environment.

Is APIM required for security?

No. APIM is an optional audit/routing path. Do not enable gateway-only production modes until E2E verification passes.