Analysis on enterprise AI governance, inline policy enforcement, agentic AI security, and regulatory compliance.
Jasper secures workspace access through SAML SSO, role-based permissions, and a 90-day Audit Log tracking membership and role changes. Content and API access are gated separately through workspace roles and scoped API keys. None of these controls inspects the content of a specific generation request against the sensitivity of the brand or customer data feeding it. This piece maps where each control ends.
Read post →Intercom secures Fin and the broader workspace through three separate mechanisms: teammate seat types and custom roles, API access tokens and OAuth scopes, and Regional Data Hosting across the US, EU, and Australia. Each answers a different question about who can reach the workspace and where data sits. None evaluates the content of a specific customer conversation Fin resolves on its own. This piece maps where each control ends.
Read post →Intercom logs Fin AI Agent activity in two separate places: conversation-level metadata showing whether an AI Agent or a teammate handled a case, and Teammate Activity Logs recording admin configuration changes. Neither was built to capture what a specific Fin reply pulled from, or what policy should have governed a specific customer conversation. This article separates the two and lists what a review should retrieve.
Read post →IBM watsonx.ai secures access through three separate mechanisms: an IAM role hierarchy across platform, service, and workspace levels, Service ID credentials for programmatic access, and an optional private-network-only endpoint for the Runtime API. Each answers a different question about who can reach the platform. None evaluates the content of a specific prompt a permitted caller sends on a given request. This piece maps where each control ends.
Read post →IBM watsonx.ai routes foundation model calls through Activity Tracker Event Routing, which records the caller IAM identity, the action, and the outcome in CADF format. Most production callers authenticate as a Service ID rather than a named person, so the event records which credential made the call, not which employee or agent was behind it. This article separates the two and lists what a security review should check.
Read post →CVE-2026-48710, disclosed by X41 D-Sec during an OSTIF-sponsored audit and nicknamed BadHost, lets a single malformed character in an HTTP Host header bypass path-based authentication middleware in Starlette, the ASGI framework underneath FastAPI, vLLM, LiteLLM, and most MCP servers. CISA added it to the KEV catalog on September 2, 2026. The bug sits a layer below the AI gateway a team actually chose, which is the argument for enforcing authorization at the request boundary instead of trusting framework middleware.
Read post →CVE-2026-59822 lets an attacker reach LiteLLM MCP tooling with a fabricated Authorization header, because a failed key check fell back to an empty UserAPIKeyAuth object instead of rejecting the request. CISA added it to the Known Exploited Vulnerabilities catalog on September 2, 2026, alongside six other flaws. The bug sits in the MCP session boundary, not the general proxy API, which is a different failure mode than LiteLLM'"'"'s earlier CVE-2026-12773.
Read post →This UK ICO AI guidance compliance checklist converts the regulator's current AI chapters into eleven gradable tests for governance, transparency, lawfulness, fairness, accuracy, minimisation, security and rights. It records the guidance review warning and verifies operative duties against current UK data protection legislation.
Read post →AI agent identity has blurred into one marketing message, but the tools underneath do distinct jobs. This buyer guide sorts the field by function: non-human identity security platforms (Astrix, Oasis, Token Security), workload identity brokers and cloud-native IAM (Aembit and the cloud providers), and runtime enforcement plus per-decision audit on the live AI call. Each entry is honest about what it secures and where its boundary sits.
Hugging Face secures the Hub and Inference API through three separate mechanisms: fine-grained access tokens with org-level roles, private or gated repositories, and network isolation options on Inference Endpoints. Each answers a different question about who can reach a model. None of the three evaluates the specific prompt a specific authenticated caller sends on a given request. This piece maps where each control ends.
Read post →Hugging Face logs Inference API and Inference Endpoints traffic against an API token and an organization account. That record supports billing and rate-limit troubleshooting. A security review needs a different record, one that ties a specific hosted-model request to the actor who sent it. This article separates the two and lists what a review should retrieve.
Read post →HubSpot scopes CRM permissions to what a user can open in the UI, one record at a time. Breeze agents assemble content from many records into a single prompt before that prompt reaches the underlying model, a step the permission model was never built to re-evaluate. This piece maps where the UI control stops and where request-level policy needs to pick up.
Read post →