Feature Reference
Technical breakdown of every IntraSage capability. Use this as a reference during evaluation or deployment planning.
Login and identity.
IntraSage supports multiple authentication mechanisms to fit existing organizational identity infrastructure without requiring a separate credential silo.
Username and password
Local credential store with configurable password policies, expiry, and complexity requirements.
SSO — SAML 2.0 and OIDC
Connects to organizational identity providers including Azure Active Directory, Okta, and Google Workspace. Users log in through the existing provider; IntraSage does not manage the credential.
LDAP and Active Directory
Directory integration for on-premise environments. Users authenticate against the organizational directory. Group memberships in the directory can be mapped to access policies in IntraSage.
Multi-factor authentication
TOTP-based MFA for local accounts. In SSO configurations, MFA enforcement is delegated to the identity provider.
SCIM provisioning
Automated user lifecycle management — create, suspend, and deprovision accounts from the identity provider without manual intervention in IntraSage.
Session management
Configurable session duration and idle timeout. Token refresh is handled server-side. Session revocation is available from the admin panel.
Retrieval-augmented generation.
Answers are grounded in documents the requesting user is authorized to access — not in model memory. The underlying model is not retrained or fine-tuned on organizational data.
Retrieval-augmented generation (RAG)
Documents are chunked, embedded, and indexed at ingestion time. At query time, relevant passages are retrieved according to the user's permissions and injected into the model context before a response is generated.
Cited responses
Every answer includes citations to the source documents and passages used to generate it. Users can follow citations to the original material to verify the answer.
Multi-turn conversations
Conversation history is maintained within a session. Users can ask follow-up questions, clarify intent, and refine requests without restating context.
Local model support
IntraSage supports customer-hosted local models for fully offline or air-gapped deployments. Documents are never sent to an external provider when a local model is configured.
Approved external model support
In hybrid configurations, approved external model providers may be used for selected, non-sensitive requests. External model use must be explicitly configured and approved — it is not enabled by default.
Model selection per deployment
Organizations choose which models are permitted for each type of information and use case. Model selection is part of the readiness assessment and deployment configuration.
Prompt and context management
System prompts, context window behavior, and instruction sets are configurable at deployment time and adjustable by administrators without redeployment.
Document ingestion and indexing.
IntraSage indexes documents from connected sources and stores the index in customer-controlled storage. The original documents are not modified.
Supported file formats
- PDF — including scanned PDFs with OCR where configured
- Microsoft Word (.docx, .doc)
- Microsoft Excel (.xlsx, .xls)
- Microsoft PowerPoint (.pptx)
- CSV and structured text
- Plain text (.txt)
- HTML and Markdown
- Email formats where connector is configured
Ingestion behavior
- Scheduled ingestion — Documents from connected sources are re-indexed on a configurable schedule.
- Manual ingestion — Individual documents or folders can be triggered for immediate indexing by an administrator.
- Incremental updates — Only changed documents are re-indexed on subsequent runs.
- OCR support — Scanned documents are processed through OCR before indexing where configured.
- Chunking strategy — Documents are split into overlapping passages before embedding. Chunk size and overlap are configurable at deployment time.
Users, roles, and document permissions.
Access is enforced at retrieval time. Connecting a source does not automatically expose its content to all users — permissions are enforced per user, role, department, and document.
Role-based access control
Users are assigned roles that define which document sets, sources, and capabilities they can access. Roles are configurable and can be mapped from directory groups.
Department and group policies
Access policies can be scoped to departments, groups, or project teams. A document available to Finance is not automatically available to HR, even within the same deployment.
Document-level permissions
Individual documents can be restricted to specific users or roles beyond the source-level policy. Source-system permissions (SharePoint, Google Drive) are carried through where the connector supports it.
Retrieval enforcement
Permission checks are applied at query time, not at ingestion time. A change to a user's role or a document's access policy takes effect immediately for subsequent queries.
User provisioning
Users can be added, modified, and deactivated from the admin panel or via SCIM from the identity provider. Deactivated users cannot query or access the system.
Access audit
Every query produces an audit record showing which user queried, which documents were retrieved, and what response was generated. Audit records are stored in customer-controlled storage.
Shared conversations and team knowledge.
IntraSage supports shared workspaces, team conversations, and persistent notes alongside individual user sessions.
Shared chat rooms
Teams can work in shared conversation spaces. Queries and responses are visible to all members of the room, subject to each member's access permissions.
Persistent notes and annotations
Users and teams can attach notes to conversations and documents. Notes are stored in customer-controlled storage and persist across sessions.
Conversation history
Individual conversation history is retained and searchable, subject to the configured retention policy. Administrators can define retention duration and purge schedules.
Shared queries
Frequently used queries can be saved and shared with team members or across the organization, subject to access policy.
Supported connectors and source systems.
IntraSage can be configured to ingest documents and structured data from a range of sources. Connector availability depends on the deployment configuration.
Microsoft 365 and SharePoint
Documents, sites, libraries, and lists. SharePoint permissions are carried through to IntraSage access policies where the connector is configured to do so.
Microsoft Teams and Outlook
Selected Teams channels and Outlook mailboxes, where permitted by organizational policy and configured in the deployment.
Google Drive and Google Workspace
Files, shared drives, and Google Docs. Google Drive permissions are carried through where the connector supports it.
Notion and Confluence
Internal knowledge bases via API integration or export, where the integration is configured at deployment time.
Slack
Selected channels and direct messages where permitted by organizational policy.
Document files and local storage
PDF, Word, Excel, CSV, PowerPoint, and plain text files from local or network storage, S3-compatible object storage, or Azure Blob Storage.
Databases and internal APIs
Structured data from customer-managed PostgreSQL, MySQL, or internal REST APIs where an approved integration is defined.
Not every connector is available in every deployment configuration. Connector availability is confirmed during the readiness assessment.
Administration, monitoring, and reporting.
IntraSage includes an administrative panel for managing users, sources, access policies, and system health — without requiring redeployment for most configuration changes.
Administration
- User and role management — add, modify, suspend, and remove users
- Source and connector configuration — enable, disable, and reconfigure sources
- Access policy management — create and modify role, department, and document policies
- Prompt and system instruction management — update model instructions without redeployment
- Retention and purge policy configuration
- Backup and restore — manual and scheduled backups to customer-controlled storage
Monitoring and reporting
- Query volume, response latency, and ingestion status dashboards
- System health checks — storage, model connectivity, connector status
- Audit log viewer — queryable records of all user and admin activity
- Usage reports — per-user, per-department, and per-source query volume
- Scheduled report delivery — recurring summaries to defined recipients
- Integration with customer monitoring tooling (Prometheus, Grafana, CloudWatch, Datadog)
REST API and programmatic access.
IntraSage exposes a REST API for integration with internal tooling, custom front-ends, and automation workflows.
Query endpoint
Submit natural language queries programmatically and receive cited responses. Useful for integrating IntraSage answers into internal portals, intranets, and dashboards.
Document management endpoints
List, upload, delete, and trigger re-indexing of documents via API. Supports automated document ingestion pipelines.
User and role management endpoints
Create, update, deactivate, and query users and role assignments programmatically. Enables custom provisioning flows beyond SCIM.
Audit log export
Export audit records for a defined time range in JSON or CSV format. Useful for compliance workflows and SIEM integration.
API authentication
API access is authenticated via API keys issued to service accounts. Keys are scoped to specific operations and revocable from the admin panel.
Webhook support
Outbound webhooks for ingestion completion, query events, and admin actions. Payloads are delivered to customer-configured endpoints.
Security and privacy controls.
Security configuration depends on the deployment environment. IntraSage does not claim compliance by default — security review is part of the readiness assessment.
Encryption
Encryption at rest and in transit is configured using the customer's storage and networking infrastructure. In private cloud deployments, this uses cloud-native encryption services (Azure Storage Service Encryption, AWS S3 SSE, GCP CMEK). In on-premise deployments, the customer configures storage-level encryption using their own tooling.
Audit logs
Every query, document access event, administrative action, and configuration change is recorded. Audit records include the user identity, timestamp, action, affected resource, and outcome. Logs are stored in customer-controlled storage and can be forwarded to customer log aggregation systems.
Credential handling
Credentials and access tokens used to connect to source systems are stored in customer-controlled configuration storage (environment variables, secrets managers, or Kubernetes secrets). IntraSage does not store source-system credentials in a shared database. Source access is scoped to read-only, least-privilege credentials wherever the source system supports it.
Data residency
Because IntraSage is deployed into customer-controlled infrastructure, data residency is determined by where the customer's infrastructure is located. In on-premise deployments, documents and indexes do not leave the customer's physical environment. In private cloud deployments, data residency is determined by the region the customer selects.
Air-gapped and offline configurations
Core document retrieval and question-answering capabilities can operate without an active internet connection when local models are configured. Model files, document indexes, and databases are stored inside the deployment environment. Optional internet-dependent features (external model providers, certain SaaS connectors) are not available in air-gapped configurations.
Technical stack and deployment requirements.
Infrastructure requirements vary by organization. The readiness assessment defines the specific configuration for each deployment — there are no universal hardware minimums.
Deployment formats
- Docker Compose — smaller environments and initial pilots
- Kubernetes with Helm charts — larger deployments with high-availability requirements
- Private virtual machines — single-tenant, customer-managed compute
- Customer-managed PostgreSQL — metadata and configuration persistence
- Local, S3-compatible, or Azure Blob storage — documents and vector indexes
- Local model runtimes (Ollama, vLLM) — for fully offline configurations
- GPU compute — required for customer-hosted large language models
Key components
- Vector store — Customer-controlled (pgvector, Chroma, Qdrant, or Weaviate depending on configuration)
- Object storage — Local filesystem, S3-compatible, or Azure Blob
- Identity integration — SSO, LDAP, Active Directory, or SCIM
- Monitoring — Prometheus metrics with Grafana dashboard, or native cloud monitoring
- Backup — Customer-controlled, scheduled to configured storage target
- Networking — All traffic within customer VPC or private network; no mandatory outbound traffic in local model configurations
Questions about a specific configuration?
The Readiness Assessment covers every technical requirement — infrastructure, models, connectors, security, and access design — before any deployment begins.