Frequently Asked Questions

Fail-closed means that if any governance check fails during an operation, the entire operation stops. There is no fallback, no retry, no degraded mode. This is the opposite of fail-open systems where errors are caught and ignored. In OS iXanagi, every AI action passes through pledges (declared intentions) and obligations (validation rules) before execution. If any check fails, you get a clear error – never a silent failure.

No. Fail-closed means the system stops when it should – when a governance check fails. But the boundaries are configurable through Schema, Pledge, and Obligation definitions. You control where the boundaries are. The system doesn't stop randomly; it stops precisely where you defined the limit of autonomous action.

No. Human-in-the-Loop is enforced at every critical decision point. AI proposes, humans approve. This is structural, not configurable.

Demand, Commitment, Fulfillment, Value, Financial, Relationship, Insight. Every business activity is a composition of these seven meaning flows.

This is the wrong question. The correct question is: where can you safely allow autonomous action, and where must human judgment intervene? OS iXanagi answers this through the Boundary Model – Schema defines what exists, Pledge defines what operations are possible, Obligation enforces governance checks, and Workflow composes steps with human approval gates. The answer is not a fixed level of trust, but a designed boundary.

A real case: a travel agency fully API-ized their operations – every resource accessible through structured endpoints. They connected these APIs to a ChatGPT custom GPT. The result? Completely useless.

The AI could retrieve data – hotel availability, booking records, customer history. But it couldn't understand that data: why this hotel is recommended for honeymooners but not families, why this tour needs to be rescheduled during cherry blossom season, why this customer always requests a specific guide.

This is the knowledge gap that every enterprise faces. API access gives AI data. Knowledge Ontology gives AI understanding.

Access control in OS iXanagi is not a feature configuration – it's a structural guarantee. Permissions are declared as obligations in the Boundary Model's Organization layer. This means AI agents follow the same access rules as human users – there is no separate permission system for AI. When an agent attempts an operation, the obligation layer checks its boundary before execution. If unauthorized, the operation fails closed.

Containerized platform with Docker services. Each tenant gets isolated data with shared infrastructure. Supports multiple instances, brands, and applications per tenant.

Yes. OS iXanagi includes an 8-module migration pipeline: Import (source registration and crawling), Extraction (AI-powered content analysis), Interpretation (meaning extraction), Candidates (review and approval), Mapping (structure alignment), Apply (execution with dry-run), Audit (before/after verification), and Post-Migration (coverage and health checks).

For WordPress sites, the pipeline handles both content and structure migration. No server changes required – OS iXanagi can start in headless mode, connecting through APIs while your existing site continues running.

No. OS iXanagi can start in headless mode – connecting to your existing systems through APIs without touching your current infrastructure. Your website continues running as-is. Your data stays where it is. OS iXanagi adds a governance and knowledge layer on top, and you migrate at your own pace.

Yes, in both directions. Upload: Excel files enter through the Inbound Gateway, AI analyzes the structure, converts meaningful data into Meaning Objects, and connects them to your business workflows. Export: AI Agents can aggregate data from any domain, generate reports, and output formatted Excel files through the Insight Domain. The governance layer ensures all data transformations are audited and reversible.

Yes. OS iXanagi is API-first – every operation available in the Console is also available through the API. You can build entirely custom frontends while inheriting the full governance layer. The Boundary Model applies to all operations regardless of interface – whether a human clicks a button in the Console or an external system calls the API, the same pledges and obligations are enforced.

The Console is browser-accessible on mobile devices. The AI chat interface is particularly well-suited for mobile – giving instructions to an AI agent through natural language is inherently mobile-friendly. Future plans include PWA and native app support, but the current browser experience is fully functional on mobile.

OS iXanagi takes a fundamentally different approach to security. Rather than adding security features on top of an application, the architecture itself eliminates the structures that make attacks possible.

Three layers work together:

Kernel Governance (fail-closed): Every data operation must pass through a declared Pledge. There is no raw SQL, no direct database access. If an operation is not registered in the Kernel, it simply does not exist. The system defaults to denial, not permission.

AI Agent Least-Privilege: Each AI Agent operates under a Role with explicitly defined allowed operations. Agents can only access data through the Pledge API – they cannot read source code, execute system commands, or reach internal infrastructure. Even if an agent were manipulated, its actions are bounded by structural constraints, not just policy.

Human-In-The-Loop (HITL): Every data modification is presented to a human as an Action Card for approval. No AI can unilaterally change data. In the OS iXanagi Governance Model, this HITL function represents the 'CEO function' – decisions without human presence are structurally prohibited.

Scope-based isolation ensures tenant data separation at the Kernel level. Knowledge Objects are resolved through 6 hierarchical layers (Kernel → App → Platform → Tenant → Brand → Site), and cross-tenant access is architecturally impossible.

In short: OS iXanagi security is not about building higher walls. It is about making unauthorized operations structurally impossible.

No. SQL Injection is structurally impossible in OS iXanagi.

In traditional systems, application code constructs SQL statements and sends them to the database. If user input is not properly sanitized, an attacker can inject arbitrary SQL. This vulnerability exists because the application has direct access to the database.

OS iXanagi eliminates this pathway entirely. Application code (the App layer) is prohibited from writing SQL. All data access passes through the Kernel's Query DSL, which is a declarative interface – not a string-concatenation API. The Kernel translates Query DSL calls into parameterized queries internally.

The rule is enforced at the architectural level: $pdo->prepare() and raw SQL are absolutely prohibited in the App layer. This is not a coding guideline – it is a structural constraint. Even if a developer attempted to write raw SQL, the framework provides no mechanism to execute it from the App layer.

The result: no matter what input an attacker sends, there is no pathway for that input to be interpreted as SQL.

OS iXanagi contains prompt injection through multiple structural layers, making it the most hardened area of the system.

Prompt injection – where an attacker embeds malicious instructions in content that an AI processes – is a well-known vulnerability in AI systems. OS iXanagi addresses this not with input filtering alone, but with structural containment.

Single Entry Point: AI Agents can only access data through curl commands to the Pledge API (localhost:8080/api/pledge). No other data access method exists. The Agent cannot read files, execute arbitrary code, or access databases directly.

Bash Command Restriction: Only curl and jq are permitted. Commands like docker exec, mysql, python3, node, cat, sed, and awk are blocked by server-side validation. Even if an injected prompt instructs the agent to run system commands, the execution layer rejects them.

Role Enforcement: Each Agent has allowed_pledges defining exactly which operations it can perform. An injected prompt might instruct the agent to delete data, but if the Agent's Role has no delete pledges (and no Role in OS iXanagi has delete permission), the operation is structurally impossible.

HITL as Final Defense: Even if prompt injection successfully generates a plausible-looking Action Card, a human must approve it. The approval step is not AI – it is a UI interaction by a real person reviewing the proposed change.

These layers stack: the Agent cannot escape its tools (curl only), cannot exceed its permissions (Role), and cannot execute without human consent (HITL).

No. Cross-tenant data isolation is enforced at the Kernel architecture level, not at the application logic level.

In multi-tenant SaaS systems, tenant data isolation is critical. Traditional approaches rely on application code to filter by tenant_id – but a single missed WHERE clause can expose one tenant's data to another.

OS iXanagi implements isolation structurally through multiple mechanisms:

Kernel-Level Scope: Every database query is scoped with tenant_id at the Kernel level. This is not optional application logic – it is a structural property of the Query DSL.

Knowledge Scope Hierarchy: Knowledge Objects are resolved through 6 layers (Kernel → App → Platform → Tenant → Brand → Site). A Tenant B query never resolves Tenant A's objects because the scope resolution chain physically cannot reach them.

AI Agent Scope: When an AI Agent is launched, its context includes tenant_id. The Agent's Pledge API calls automatically carry this scope. The Agent has no mechanism to specify a different tenant_id.

Platform Knowledge (tenant_id=0) is the only shared layer – it contains generic operational knowledge (like 'what is ACCA framework') that is safe for all tenants to read. Tenant-specific business data never enters this layer.

The separation is architectural, not policy-based. There is no configuration setting that could accidentally expose cross-tenant data.

No. OS iXanagi enforces a restrict-only principle that makes privilege escalation structurally impossible.

In traditional systems, gaining administrator access is the primary goal of an attacker. Once elevated, an attacker can access all data, modify configurations, and create backdoors.

OS iXanagi uses a hierarchical permission model where each lower level can only restrict – never expand – what the level above permits:

• Platform (super_admin) sets the maximum bounds for all permissions
• Tenant administrators can restrict permissions below Platform defaults, but cannot exceed them
• Brand and Site levels can further restrict, but never escalate

For AI Agents specifically: each Agent operates under a Role with allowed_pledges. A tenant admin can disable write access for a role (can_write: false), but cannot enable write access if Platform defines it as read-only. The Settings system enforces bounds – for example, a tenant cannot upgrade chat_assistant from Sonnet to Opus, only downgrade it to Haiku.

Even if a tenant administrator's account is compromised, the attacker:

• Cannot access Platform-level settings (tenant_id=0)
• Cannot modify Role definitions beyond restrict-only bounds
• Cannot access other tenants' data (scope isolation)
• Cannot bypass HITL approval requirements

OS iXanagi combines structural prevention with comprehensive audit trails to address data tampering.

Prevention through HITL: No AI Agent or automated process can modify data without human approval. Every write operation passes through the Action Card → Approve flow. The approval is not a software flag – it is a deliberate human action in the console UI. This means that even if an internal process is compromised, it cannot silently alter data.

Knowledge Proposal Flow: Changes to Knowledge Objects – the most critical data in OS iXanagi – follow a dedicated proposal pipeline. An App or AI Agent submits a proposal, which appears in the Knowledge Console Inbox. A human reviewer accepts, rejects, or modifies it. The proposal history is permanently recorded.

Audit Trail: All AI operations are logged across three tables:

• ai_conversation_sessions: Who initiated, when, in which module
• ai_conversation_turns: Every message, every AI response, every tool call
• ai_action_audit_log: Before/after JSON for every Action Card execution

Detection and Recovery: If unauthorized changes are detected through audit review, the before/after JSON provides the exact state needed for recovery. Knowledge Object history maintains the full change chain.

No Role in OS iXanagi has delete permission. Deletion is exclusively a human action performed directly in the console. This means even a fully compromised AI Agent cannot destroy data.

Infrastructure-level protections (database backups, encryption at rest, TLS in transit) complement OS iXanagi's application-level safeguards and are managed at the deployment layer.

OS iXanagi addresses major attack categories not with patches or add-on security layers, but with structural design that prevents them from occurring in the first place.

The key areas of protection include: SQL Injection (structurally impossible through Query DSL), unauthorized API access (sealed by the Pledge system), privilege escalation (blocked by restrict-only design), AI prompt injection (contained by single entry point and Role enforcement), cross-tenant data leakage (prevented by Kernel-level scope isolation), and data tampering (tracked through comprehensive audit trails).

Each of these protections is detailed in its own FAQ entry below. The common principle across all of them: even if an attacker gains access, no meaningful unauthorized operation can succeed – because Pledges gate every action, Roles limit every agent, and humans approve every change.

No. Hidden APIs cannot exist in OS iXanagi.

In traditional REST or GraphQL systems, APIs are defined as URL routes or resolvers. Attackers commonly discover undocumented endpoints through enumeration, directory scanning, or reverse engineering. A forgotten debug endpoint or an unsecured admin API can be catastrophic.

OS iXanagi has no 'endpoints' in the traditional sense. Every operation is a pledge_set – a declared contract registered in the Kernel's registry database. The Kernel Dispatcher only processes operations that exist in this registry. If a pledge_set is not registered, the Kernel returns a fail-closed rejection.

This means:

• There is no URL routing that could expose unexpected paths
• There is no controller that could be accessed directly
• There is no 'admin mode' that bypasses the Pledge system
• Every operation is explicitly declared with its handler, permissions, and validation rules

An attacker guessing pledge_set keys gains nothing – the registry validates not only that the key exists, but that the caller has the required context (tenant_id, site_key, authentication).