SAFi v1.5.0 Released: New Capabilities for Enterprise-Grade AI Governance

SAFi v1.5.0 delivers local sensitive data screening, IAM integration, security hardening, and approval workflows for AI controllability.
SAFi v1.5.0 centers on giving enterprises actionable control over AI data access, tool invocation, collaboration, and auditing. It screens SSNs, credit card numbers, and bank routing numbers locally before prompts leave, with legal hold pausing record destruction. On identity, it adds Microsoft Entra ID SSO, TOTP MFA, SCIM 2.0 provisioning, and automated deprovisioning. Security gains signed-manifest verification, prompt injection screening on tool results, SHA-256 checks, and unprivileged containers. Collaboration adds granular sharing and an Attention Inbox with dual approval. It also introduces versionless model identifiers and PDF/Word/Excel/Markdown export.

Enterprise AI adoption is shifting from "can we use it" to "dare we use it." The release of SAFi v1.5.0 is a direct response to that shift—not a simple stacking of features, but a release built around a single throughline: giving organizations actionable control over AI system data access, tool invocation, human collaboration, and audit outcomes.
Sensitive Data Protection: Putting the Line of Defense Locally
SAFi now performs sensitive information screening locally, before a prompt is sent to an external model provider. Detection covers Social Security numbers, credit card numbers, bank routing numbers, and related identifiers.
The key here is "local"—sensitive data doesn't have to leave the organization's boundary before being intercepted. When SAFi blocks a prompt, the user receives a clear explanation rather than a generic error code. Legal hold also suspends related record destruction and redaction routines, ensuring data isn't accidentally purged in compliance scenarios.
For heavily regulated industries such as finance, healthcare, and legal, this "screen first, then transmit" path is more practically binding than after-the-fact auditing.
Enterprise Identity and Access Management: Plug Into Existing Infrastructure
SAFi v1.5.0 lets organizations connect to their existing identity systems, covering the following capabilities:
- Microsoft Entra ID single sign-on
- TOTP multi-factor authentication
- SCIM 2.0 user and role provisioning
- Automated account deprovisioning
- DNS-based domain verification
- Tenant-aware workspace routing
The value of this set of capabilities lies in handing responsibility for user lifecycle management back to the enterprise's existing IAM systems, rather than requiring administrators to maintain a parallel set of accounts inside SAFi. The introduction of SCIM 2.0 means permission changes for onboarding, role changes, and offboarding can flow automatically, reducing access risk from human oversight.
SCIM 2.0 (System for Cross-domain Identity Management) is an open standard protocol for cross-domain identity management, published by the IETF as RFC 7642/7643/7644. It defines standard REST endpoints and JSON schemas, enabling identity providers (such as Entra ID and Okta) to automatically push user and group creation, update, and deactivation events to applications. Compared with vendor-proprietary synchronization interfaces, SCIM 2.0 makes "provision access automatically on onboarding, revoke access automatically on offboarding" a universal cross-system capability, sparing administrators from manually maintaining the same roster across multiple systems.
Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud identity and access management service, widely used for enterprise single sign-on, conditional access policies, and multi-factor authentication. Connecting SAFi to Entra ID means users can log in directly with their existing enterprise credentials without creating a separate password in SAFi; permission groups and roles can also be synced from the directory service, remaining consistent with existing account lifecycle processes.
TOTP (Time-based One-Time Password) is the multi-factor authentication algorithm defined in RFC 6238, generating a 6-digit verification code from a shared secret and the current time window, typically produced by authenticator apps. It doesn't rely on SMS or hardware tokens, has low deployment cost, and is well suited as a second factor for enterprise login.
Security and Integrity: From Deployment to Runtime
Administrators can use the Verify this Install feature to compare the actual deployment against SAFi's signed release manifest, confirming the installation hasn't been tampered with.
This version also adds or strengthens the following measures:
- Prompt injection pattern screening on results returned by external tools
- SHA-256 package and dependency verification
- Updated server and document-parsing dependencies
- Running in unprivileged Docker containers
- Removal of credentials from subprocess environments
- Removal of the ability to dynamically install npm packages at runtime
Together, these changes shrink the deployment risk surface. Particularly noteworthy is injection screening on external tool results—when an AI system calls third-party tools, the returned content itself can become an attack vector, and this layer of screening fills another gap beyond prompt security.
Prompt Injection refers to an attacker hiding malicious instructions in content that an AI system reads, inducing the model to deviate from its original task, leak system prompts, or perform unauthorized actions. It can be divided into direct injection (a user constructing a privilege-escalation instruction directly in the input) and indirect injection (malicious content hidden in web pages, documents, or third-party tool results that triggers when read by the AI). For Agents that call external tools, the indirect injection risk is especially pronounced—the text returned by a tool is itself untrusted input. SAFi's injection pattern screening on external tool results moves the protection point forward to the critical juncture where "tool output enters the model context."
A signed manifest is a common practice for software supply chain integrity: the publisher signs a manifest listing all files and their hashes with a private key, and the installer verifies the signature and hashes with a public key, confirming the received software package was indeed published by the official source and hasn't been tampered with. Verify this Install is based on this mechanism, allowing administrators to check at any time whether the current deployment matches the official manifest.
Team Collaboration and Approval Workflows
Users can share conversations, research threads, and knowledge folders with colleagues or specified groups. Fine-grained permissions control who can view or edit shared resources, and a dedicated Shared with Me view separates collaborative content from personal conversation history.
The new Attention Inbox provides a unified entry point for centralized review of:
- Account and role access requests
- Tool permission requests
- Security notifications
- Compliance alerts
Access to privileged tools can require approval by a second authorized administrator, thereby supporting separation of duties. Requesters can also track the status of their submitted requests.
This design turns "who can call which tools under what conditions" into an explicit, approvable process rather than a default allow.
Separation of Duties (SoD) is a core principle in internal controls and compliance auditing: critical operations should not be completed independently by a single person, but require at least two people participating in distinct roles, to reduce the risk of errors and internal fraud. On an AI platform, this principle typically manifests as "dual approval for privileged tools"—a requester submits a tool permission request, a second authorized administrator reviews and approves it, and neither party can complete the entire chain alone. SoD is common in audit-constrained scenarios such as finance, healthcare, and government, and is also a key control examined by frameworks such as SOC 2 and ISO 27001.
Model Catalog, Export, and Platform Updates
SAFi v1.5.0 introduces more model integrations and stable versionless model identifiers. This means backend model versions can be swapped without breaking saved prompts, bookmarks, or configurations.
Governed answers and completed conversation turns can be exported as PDF, Microsoft Word, Microsoft Excel, and Markdown, making it easy to move reviewed outputs into reports, records, and operational processes.
Additionally, Agents can run on daily or weekly schedules and send summaries by email, with summary content converted from Markdown to branded HTML. SAFi also supports Progressive Web Apps (PWA), installable in modern browsers on desktop and mobile; the Service Worker is limited to static assets, and governance state, policy definitions, and ledger records are not cached.
On the platform support front, MySQL 8.4 LTS becomes the standard supported database target, with support for Python 3.11, 3.12, and 3.13; SCIM 2.0 endpoints require HTTPS, and tool integrations use vetted Python modules and standard MCP servers.
A versionless model identifier refers to a class of stable logical names—an alias like "a general-purpose chat model," for example—rather than a hardcoded reference bound to a specific version number (such as GPT-4o-2024-08-06). The backend can swap the actual model version behind the identifier while the caller's saved prompts, bookmarks, and Agent configurations remain unchanged. This matters greatly for enterprises: model provider version iterations often come with differences in behavior, pricing, or capabilities. If identifiers are tightly bound to versions, every upgrade means a full configuration migration and regression test; using versionless identifiers turns "model switching" into a controllable operational action.
MCP (Model Context Protocol) is an open protocol for connecting AI applications with external tools and data sources, defining a standard interaction between clients and servers so the same tool server can be reused by different AI frontends. SAFi's use of vetted Python modules and standard MCP servers means tool integrations follow a unified contract, which both facilitates auditing and reduces the risk of each integration going its own way.
A Pragmatic Step in Enterprise AI Governance
The feature list of SAFi v1.5.0 reflects a trend: AI governance is no longer a compliance label bolted onto a model, but an engineering capability embedded in identity, data flows, tool invocation, and approval chains. From local sensitive data screening to signed manifest verification, from SCIM provisioning to separation of duties in the Attention Inbox, these features together answer a question—how can an organization enjoy AI capabilities while maintaining real control over "how AI systems access data, use tools, collaborate with people, and produce auditable results"?
For organizations evaluating enterprise-grade AI platforms, we recommend validating the upgrade path in a test environment and confirming item by item against the release notes how well your own compliance requirements are covered.
Related articles

Gaussian Process Bandit Optimization: Exploration Strategies and Inference Regret Guarantees
Cumulative regret guarantees in Bayesian optimization fail to reflect final recommendation quality. This article examines a new study that provides inference regret guarantees for Gaussian process bandit optimization through exploration query strategies and fill distance analysis, validated on hyperparameter optimization and control tasks.

The Most Detailed Codex Guide on Bilibili: From Installation to Real-World Practice
The most detailed Codex guide on Bilibili: from app store installation to daily work mode configuration, with a real coffee shop project demonstrating file organization, data extraction, dashboard creation, and other practical tasks. Learn to use Plan Mode and desktop pets to leverage Codex efficiently.

Appearance Compensation in Volume Rendering: Why RGB Accuracy Cannot Guarantee Density Correctness
Volume rendering research reveals that volumetric data perfectly reproducing external RGB views may still contain density errors: appearance compensation can double central density and keep external rays unchanged even when L2 error exceeds 14.52%. Density recovery depends on appearance capacity, spatial resolution, and measurement design.