Last updated: September 12, 2026
Definitions and verified context
Define the security vocabulary up front so answer engines can extract precise chunks. Untrusted data can trick an over-privileged agent into misusing tools it is allowed to call — the Confused Deputy (OWASP ASI03). Kimss closes that gap with an Authority Boundary mid-loop.
- Agent kill switch
- An authoritative gateway control that refuses further traffic for a disabled agent while retaining the audit trail.
- Authority Boundary
- Kimss guardrail that validates tool-call argument provenance mid-loop so agents cannot widen privilege through confused-deputy patterns. Beyond caller authentication that basic gateways stop at.
- Threat Intercept
- A blocked-traffic record (reason + sanitized excerpt) written when content safety, egress gates, or argument policies stop a request.
- Confused Deputy (ASI03)
- OWASP Top 10 for Agentic Applications 2026 category for identity and privilege abuse: the agent keeps legitimate tool access while attacker-controlled content supplies the arguments.
OWASP ASI03 (Identity and Privilege Abuse) covers agents that inherit excess privilege when tool arguments are not provenance-checked.
Source: OWASP Agentic Security Initiative — Top 10 for Agentic Applications 2026
“The root cause is a trust gap between connect-time and runtime. Tool descriptions are reviewed once, when the agent first connects to a server. Tool responses go straight into the LLM’s context with no equivalent check.”— OWASP Foundation, MCP Tool Poisoning attack page
Kimss keeps an audit log of administrative actions and governed requests, with configurable retention. Gateway-verified attribution applies to routed traffic; see the compliance framework mapping.
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. Governed-request 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.
- governed requests 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_compliance for system design, and /docs/trust_safety for guardrail posture. Enterprise customers engage /enterprise for deeper evidence packages.
Builders should prefer /v1 over legacy assistant endpoints so metering and identity behavior stay current—see /assistants-to-v1-migration.
Hermis intercepts MCP tool_call output before internal infrastructure: kill switch, in-memory Key Vault unwrap, then tenant audit_log. See Trust Center.
Compliance framework mapping
Procurement checklists for ISO/IEC 42001, EU AI Act record-keeping themes, and NIST AI RMF map to concrete Kimss features—including the admin agent kill switch.
See the full mapping at /docs/compliance_framework_mapping. This is alignment guidance, not a certification claim.
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 governed-request exhaustion behavior as a security control against resource abuse, not only a finance feature. Use Manage Agents to disable compromised or stale agents without deleting their configuration.
Frequently asked questions
Does Kimss prevent prompt injection?
Kimss focuses on platform controls (keys, tenancy, governed requests, audit). Application-level prompt defenses and Content Safety policies remain part of your Azure and app design. Guardrails at /app/guardrails can enable Prompt Shields on input, tool context, and output.
Where is the security architecture documented?
Start at /trust, then /docs/security_compliance and /docs/trust_safety.
How do we limit tool blast radius?
Use Kimss tool-name allowlists and argument-level tool policies (Production+) so agents can only pass approved values—for example email to must match your company domain. Pair that with least-privilege service identities and workspace-scoped Kimss keys 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.
What does a blocked request record, and can it be exported to our SIEM?
Blocked gateway traffic (content safety, egress gates, argument-policy violations, or PII scrub) writes a Threat Intercept row with timestamp, agent identity, trigger reason, and a sanitized excerpt—not a full prompt archive. Scale and Enterprise include Export to SIEM (JSON/CSV); Enterprise can stream threat_intercept.recorded to NOC webhooks.
Are there per-agent spend caps?
Yes. Per-agent monthly token budgets (monthly_token_cap / cap_action alert or block) are enforced when traffic carries X-Kimss-Agent-Id; block returns HTTP 429. Vault endpoints can also set per-endpoint monthly_token_cap. These are provider-spend guardrails, not Kimss governed-request billing.