Bayani.ai is designed as a secure middle tier, not a direct pass-through to model vendors.
The platform is built around a simple security principle: end users should never receive Bayani-managed Azure credentials, direct access to Bayani-managed model infrastructure, or unconstrained tool authority. Identity, tenant routing, role checks, quota enforcement, memory scope selection, and integration approvals remain on the server side.
That posture shapes the rest of the system. Bayani.ai uses organization-scoped access, role-based permissions, hashed credentials and tokens, append-only auditability, and explicit control over which tools and workflows can act on external systems.
Centralized policy enforcement before model, memory, search, or MCP tool access is allowed.
Human approval remains the expected gate for consequential actions that change external state.
Security starts with the middle-tier boundary.
Bayani.ai is designed so users interact with Bayani-managed application hosts rather than directly with Azure AI services, model vendors, or tool backends.
The Bayani backend acts as the secure middle tier for agent interactions. Tenant routing, authorization checks, subscription and quota enforcement, memory scoping, and tool policy all stay inside Bayani-controlled server-side code.
End users do not receive Bayani-managed Azure credentials and do not call Azure AI Foundry, Azure AI Search, or Bayani-managed MCP services directly. That separation reduces credential sprawl and keeps policy enforcement centralized.
Application hosting is designed for Windows Server and IIS, with platform services and MCP integrations exposed through controlled HTTP endpoints rather than ad hoc client-side connections.
- > No direct credential exposure to end users for Bayani-managed Azure or integration resources.
- > Central policy enforcement happens before model, memory, retrieval, or tool access is allowed.
Account protection includes strong credential handling and session control.
Bayani.ai supports local and federated sign-in patterns while keeping authentication controls and security lifecycle events inside the platform boundary.
Passwords are stored only as strong one-way hashes, never in plaintext. The platform is designed to support password reset, email verification, failed login tracking, account lock states, session management, and session revocation.
Email is treated as a core user identifier, and linked authentication methods can coexist for the same internal user record when local and external identity providers are both used.
Session tokens and reset tokens are handled as revocable security artifacts rather than durable shared secrets, supporting the ability to invalidate active sessions when risk or policy requires it.
- > Failed login activity is a first-class security signal, not just a UX concern.
- > Session revocation support is part of the expected operating model when access needs to be cut off quickly.
Access is organization-scoped and permission-driven.
The platform uses an organization-centric account model so billing, quota enforcement, agent assignments, and API access all inherit the same tenant boundary.
Access to organization data is determined through membership, roles, and permissions rather than scattered flags. The role model is designed around explicit authorization boundaries such as Owner, Admin, Billing Admin, Developer, and Viewer.
Organization and personal AI memory are intentionally separated through distinct scopes so official company context and individual user context do not bleed into one another.
Knowledge retrieval is designed around tenant-scoped indexes and server-side routing so one organization's search, memory, and workflow context are not shared with another's.
- > Role-based access control is the intended baseline for who can prompt, approve, configure, and administer.
- > Dual-profile memory scoping keeps organization and personal conversational context isolated.
External actions are gated through scoped tokens and controlled MCP access.
Bayani.ai treats tool access as part of the security model, not as an afterthought added after model output is generated.
API tokens are organization-owned and are expected to support scope-based permissions, expiration, revocation, and usage tracking. Raw API tokens are not stored directly in the database; only safe derived values such as hashes and lookup prefixes are retained.
Platform-managed MCP tools are hosted through Bayani-controlled endpoints. Customer custom MCP endpoints are treated as higher-risk integrations and are expected to pass validation, timeout, rate-limit, and security review controls before activation.
Tool access is determined by the organization's active product and add-on scope so the model cannot assume universal authority across web search, document generation, email, calendar, task systems, or custom endpoints.
- > Hashed token storage reduces exposure if a database record is compromised.
- > Custom MCP endpoints are expected to operate behind validation, rate limiting, and automatic disablement on repeated failures.
Security depends on keeping different data responsibilities in different systems.
Bayani.ai intentionally separates identity and platform control data from retrieval systems, memory systems, and website search infrastructure.
PostgreSQL is the local system of record for identity, tenancy, billing, platform metadata, usage, and audit information. Customer knowledge retrieval is handled through Azure AI Search, while conversational memory is handled through Azure AI Foundry memory scopes.
Qdrant is reserved for Bayani-owned platform vector collections such as website articles and development collections rather than customer tenant knowledge. That prevents the public-site search layer from becoming a shadow store for tenant content.
Security-sensitive provider credentials for chat and conference integrations are designed to be stored encrypted rather than as plaintext configuration values.
- > Separation of storage responsibility helps reduce accidental cross-use of identity, tenant, and retrieval data.
- > Encrypted credential storage is the expected baseline for provider secrets and integration access.
High-value security controls are backed by append-only evidence.
Bayani.ai treats usage tracking, audit logging, and quota enforcement as operational security features as much as platform accounting features.
Usage events and audit logs are designed as append-only event streams with time-based partitioning. This supports traceability for actions such as login events, password reset activity, API token lifecycle changes, tool use, subscription changes, and quota enforcement actions.
Quota checks use current usage-period state for fast enforcement while retaining raw events as the historical source of truth. That means restrictions can be applied quickly without sacrificing auditability.
MCP tool invocations and other cross-system actions are expected to generate usage and audit evidence so investigations, support review, and compliance-oriented reporting have a durable trail to work from.
- > Append-only records protect the integrity of operational history.
- > Security events and usage events are retained because accountability is part of the product design.
Reasoning may automate, but consequential action should stay reviewable.
Bayani.ai is designed around governed AI operations where the highest-risk transitions are visible, reviewable, and attributable.
The platform is intended to support human-in-the-loop approval for consequential actions such as sending communications, changing records, invoking external tools with persistent side effects, or triggering production workflows.
This pattern keeps the distinction clear between AI reasoning and AI action. The system can search, draft, summarize, and recommend broadly, while approvals remain with authorized human operators.
That same approval model supports both internal governance and external trust by pairing action history with approving identity, timestamp, and surrounding operational context.
- > Approval gates are part of the security posture, not friction added after deployment.
- > Auditability matters most where workflows can change data, send messages, or affect third-party systems.
Security questions should be discussed in deployment context.
If your organization needs a deeper review of identity, tenant isolation, MCP controls, storage boundaries, retention, or approval design, Bayani.ai can walk through the relevant deployment scope before launch.
General questions may be directed to contact@bayani.ai.
Customer-specific security, privacy, compliance, or architecture reviews should be handled as part of the relevant pilot, subscription, or enterprise engagement so controls can be assessed against the actual deployment model.
- > Contact: contact@bayani.ai
- > Recommended practice: review integrations, roles, data classes, and approval paths before production go-live.
Bring the deployment scope, integrations, and approval model.
If your organization needs a deployment-specific walkthrough covering identity, tenant scoping, tool controls, audit requirements, or integration boundaries, contact Bayani.ai before rolling live workflows into production.