Know the User and Tenant
Establish the user, service identity, role, tenant and permitted operating scope.
MedhaOS keeps identity, permissions, policies, approvals, audit and deployment boundaries around AI-enabled work so people remain in control of what the system may see, suggest and do.
AI can interpret, investigate and propose useful work. That does not mean it should automatically gain access, approval rights or unrestricted execution power.
The system cannot reliably apply the right access and responsibility without knowing the user, tenant and role.
Helpful reasoning can turn into unapproved action when permission and approval boundaries are not explicit.
Teams struggle to reconstruct which information, policy, approval or tool produced an outcome.
Data, model endpoints and enterprise integrations can move beyond the intended operating boundary without clear controls.
MedhaOS separates intelligence from authority so enterprise teams can define who may access, approve, execute and override AI-enabled work.
Connect users, groups, roles and service identities to the context, tools, routes and actions they are allowed to use.
Maintain customer, workspace, user and data boundaries according to the deployment and operating model.
Apply policies to what the system may see, retain, suggest, route, execute, escalate or block.
Keep consequential actions answerable to authorised people through explicit approval and escalation paths.
Preserve requests, evidence, model or rule paths, policy checks, approvals, exceptions and outcomes.
Provide operational visibility into routes, model usage, policy outcomes and cost-aware governance.
Reasoning, permission, approval and execution remain separate responsibilities.
Establish the user, service identity, role, tenant and permitted operating scope.
Apply data access, retention, model, route, tool and action constraints.
Let Medha retrieve and reason only within the approved context and capability boundary.
Escalate sensitive, irreversible or exceptional actions to an authorised person.
Run only permitted tools and preserve the decision and execution history.
Keep operational override, interruption and correction paths available when they are needed.
Security matters most when legitimate authority can still change what the system is allowed to do.
Expose tools and APIs according to identity, tenant, route and task requirements rather than platform-wide convenience.
Filter, de-identify, retain locally or rehydrate sensitive information inside controlled boundaries.
Place control, data-handling and execution components according to customer infrastructure and policy requirements.
Governance controls should be configured and tested against the real identity, authority and operating boundaries of each implementation.
Test identity, tenant, policy, approval and audit controls against the implementation.
Business and technical owners remain accountable for consequential actions and operating changes.
Validate identity providers, permissions, retention and deployment boundaries for the environment.
Continue into governance, deployment and a guided MedhaOS walkthrough.
Review identity, tenant, policy, privacy, approval, audit and operational override principles.
Compare cloud, private cloud, hybrid and customer-controlled deployment patterns.
Follow identity, permitted tools, policy, approval, execution and audit evidence in one guided scenario.
Concise answers to common evaluation questions, using the same governed product and capability definitions as the rest of this page.
MedhaOS is Sastra's governance and execution-control layer for enterprise AI, designed to manage identity, permissions, policies, approvals, tenant boundaries, auditability and controlled model or tool execution.
Medha focuses on reasoning, context, retrieval and orchestration. MedhaOS focuses on authority and control: who or what may access information, which actions are allowed, when approval is required and how execution can be audited.
Within verified implementation scope, MedhaOS is designed around identity and RBAC, tenant boundaries, policy enforcement, approval gates, model and tool permissions, auditability and controlled execution boundaries.
A system being capable of reasoning about an action does not mean it should automatically be allowed to perform that action. Separating intelligence from authority makes permissions, policies, approvals and accountability explicit.
No. Governance and security controls do not by themselves establish certification or blanket compliance. Compliance depends on the full implementation, operating processes, deployment scope and any required independent validation.