Ekaya Enterprise
Custom applications inside your boundary.
Built and installed for your organization.
Builders deliver outcomes with their own coding agent, as applications that run inside your organization's data boundary, against your own data and services. Every one of them reaches that data through a single layer your security reviewer can read.
Inside your boundary, every request meets one layer and leaves one record.
Illustration. Inside one organization's boundary, an invoice exceptions application, Claude Code working for an employee, and a nightly reconciliation job reach the organization's ERP, operations database, warehouse, and analytics database only through the Data Access Layer, Ekaya Gateway, which runs with no live LLM in the data path. For each request it checks who is asking, which approved Request it is, and what policy says. Five example requests: the application reads flagged invoices as Sofia Nunes and is allowed three rows; the agent reads depot shift numbers with the driver phone column masked; the agent asks for years of delivery history and gets the Request's limit of 500 rows; the agent's raw query against payroll is blocked because no approved Request matches; and the job's hold_invoice Action reaches the ERP, which times out, so the outcome is recorded as indeterminate, an alert is raised, and it is not retried. Every request leaves a line in the audit record.
The Data Access Layer
Every application, agent, and automation reaches data through one layer.
This is where your security reviewer is pleasantly surprised. Bring the review: here are the questions it will ask, how the layer answers each one, and the evidence to ask us for.
Where it starts
It starts with your employees.
They use Ekaya project by project, the way a solopreneur does: an ops lead or a data-platform admin with a coding agent builds the internal tools nobody else will get to, against your own data and services, without data leaving the boundary. Ekaya Enterprise is the company-wide conversation that follows.
Internal-tool requests queue behind IT, and the backlog decides what gets built by sequence, not importance. Builders with a coding agent can clear their own, and their co-workers just open what they build.
Built and shared by employees: three applications, seven people, one boundary.
Illustration. Inside one organization's boundary, three employees built applications with their coding agent and shared them with co-workers: Amara Osei in Procurement built a carrier scorecard that runs in the cloud, used by Rosa Kim in Procurement and Lior Adler in Finance; Jonas Lindqvist in Operations built a shift handoff that runs across your cloud and your data center, used by Dev Mehta, a depot lead; Mei Tanaka in Finance built an invoice exceptions app that runs on-prem, used by Lior Adler and by Sofia Nunes in accounts payable. Inside the boundary, people sign in with the organization's identity provider, each application acts as the person using it, and Ekaya, the data, and the services stay there.
Who may do the work?
Every caller is named. None shares a key.
People sign in with Entra or your own identity provider and work within their Role. Their agent acts as them, and a Hosted Application acts as whoever opens it, so opening an application grants no additional Requests.
Processes hold Data Access Points, each with its own key or Entra identity and only the Requests it was granted. For the people using your own applications, a bound subject keeps each one to their own rows.
Five callers on one Project, each named, none sharing a key.
Illustration. Mei Tanaka, a Member, signs in with Entra and acts as herself in the Finance Role, running the Finance Role's Requests. Her agent, Claude Code, uses her sign-in and can do what Mei may and nothing more. The Invoice exceptions Hosted Application acts as whoever opens it, with that viewer's Requests. nightly-reconcile, a Data Access Point, is a process with its own key or Entra identity and only the two Requests it was granted. A supplier using your own portal is a bound subject: a token your issuer signs binds them to their own rows. No caller shares a key, and every one is named in the audit record.
Ask us to show you permitted and denied identities, with application and Request grants tested separately.
What may change?
Agents get approved Requests, not credentials.
A Query reads. An Action changes something, and what a Request does decides which. Agents propose Requests; an Administrator attests the effect and approves each one, which freezes its contract: the operation, typed parameters, who may run it, and how many rows it may touch. A Request that no longer matches its approval is refused.
Parameters are validated and bound, never pasted into a query. How far an agent may explore is set per Role, and exploring only reads.
An agent proposes an Action. An Administrator attests its effect, then approves it.
Illustration. In Pending Requests, Claude Code, working for Mei Tanaka, has proposed an Action named hold_invoice on the ERP: it puts one invoice on hold, takes a typed and validated invoice_id, is an UPDATE on the invoices table, may be run by the Accounts payable Role and the nightly-reconcile Data Access Point, and may affect at most one row. An Administrator attests the effect and approves it, or rejects it; until then nothing can run it. Each Role's MCP level decides how far its agents may explore: None, Minimal, Rich, or Full. Never by default: a connection string in an agent's environment, a change dressed as a Query, a schema change through a Request, or an uncertain write repeated silently.
Ask us to show you approved Requests with their effects, parameters, and row caps, and what a write does when it reaches one.
What stops misuse at the point of access?
Control in the path, not a report after the fact.
Ekaya sits in the path of every request, so it acts before data comes back: it blocks, masks, limits, and alerts, with deterministic rules that can say why they fired.
An injection attempt is refused. Sensitive columns are masked. A request over its Request's data-loss threshold is blocked, raises an alert, and costs the agent its key. Repeated failures that look like probing lock the caller out.
Watching from the side finds out later. In the path, the layer acts before data comes back.
Illustration. Out-of-band monitoring watches an agent reach your data and reports after the data has left. Ekaya sits in the path: a request reaches the Data Access Layer before the data, so the layer can block, mask, limit, or alert before anything comes back. What it detects, and how it responds: an injection attempt in a parameter is blocked; a sensitive column in a result is masked; more rows than the Request allows are limited; a request over its data-loss threshold is blocked, raises an alert, and revokes the agent's key; repeated failures that suggest probing block the caller and raise an alert; a large export or unusual volume raises an alert. Every rule is deterministic and can say why it fired.
Ask us to show you a denied attempt, the rule that refused it, and the alert it raised.
Is the business meaning right?
Meaning is approved once, and every agent inherits it.
In Ontology Forge, your builder's own agent drafts what each table, column, and term means, and people review and approve it. Requests name the glossary terms their parameters and outputs represent, so two Requests on two systems agree on what a customer is.
Sensitive columns are found by deterministic detection before an agent can see them, and selecting one takes a deliberate confirmation.
Two systems, two column names, one approved definition of a customer.
Illustration. The glossary term active customer is defined as a customer with an order or an open invoice in the last twelve months, approved by Ana Ruiz. Two Requests on two systems name it: active_accounts on the CRM, a PostgreSQL database, returns account_ref; open_invoices_by_customer on the ERP, a SQL Server database, returns cust_no; both columns are bound to the active customer term, so an application combining them agrees on what a customer is. In the same schema, contact_email, tax_id, and phone were detected as sensitive, and selecting them for agents needs a deliberate confirmation.
Ask us to show you the reviewed schema and ontology, and examples with known expected answers.
Can we reconstruct it?
Every request leaves a record you can follow end to end.
For any action, a reviewer can rebuild the chain: human → agent → request → parameters → data touched → policy decision → response → approval, reversal, or an honest terminal state.
A write that cannot be confirmed is recorded as indeterminate, raises an alert, and is never retried silently or called a success. An Administrator records what really happened once someone has checked.
One Action, on the record, from the person who asked to how it ended.
Illustration. The record of one Action, in order: the human, Mei Tanaka; the agent, Claude Code; the request, hold_invoice; the parameters, invoice_id INV-20931; the data touched, one row of invoices; the policy decision, allowed with at most one row; the response, invoice held; and the approval, attested by Sam Okafor. What an agent does while configuring the Project is recorded the same way: human, agent, tool, request, data touched. Retention follows the profile you set, with legal hold, and operational events and alerts go to your SIEM.
Ask us to show you a real permitted run and a denied attempt, with their audit records, and what is not recorded.
Where does it run, and can we read it?
Inside your boundary, with no model in the data path.
Ekaya Admin is where builders and their own AI configure each Project. Ekaya Gateway is the air-gappable server that applications, agents, and Data Access Points call in production: it performs no live LLM inference, and it cannot approve a Request or change its own rules. Its adapters are chosen at build time, so there is no egress beyond the adapters compiled in at build time.
Ekaya Gateway, the server in the data path, is committed to be open source under Apache-2.0, so the people who run it can read and audit the code entrusted with their data.
Two servers inside your boundary. Neither one embeds a model.
Illustration. Inside your boundary run two servers. Ekaya Admin is where builders and their own AI configure datasources and credentials, schema, ontology and glossary, approved Requests and policy, and Roles, Members, and Data Access Points, over MCP; it embeds no model, because the AI is the builder's own agent. Ekaya Gateway is the server Members, Hosted Applications, agents, and Data Access Points call in production. It serves approved Requests and Hosted Applications, performs no live LLM inference, has no path for improvised queries, and cannot approve a Request or change its own rules. Its adapters are chosen at build time: PostgreSQL and its family, SQL Server with Entra sign-in, and BigQuery compiled in, and the API Adapter optional, so a build without it reaches only the databases and identity provider you configure. Ekaya Gateway is committed to be open source under Apache-2.0.
Ask us to show you the deployed components, compiled adapters, credential custody, stored data, and outbound paths.
Objections, answered
“Agents will roam across our production data.”
They cannot. In production, agents reach data only through approved Requests, and Ekaya Gateway has no path for improvised queries. How far an agent may explore while building is a per-Role decision: reads only, capped, and recorded. A raw credential in an agent's environment is not an integration strategy, and Ekaya does not ask for one.
“Can we read the code that touches our data?”
Ekaya commits to publish the Gateway, the server in the data path, as open source under Apache-2.0, so its code can be read, audited, and run inside your own boundary.
“Can it run inside our boundary?”
Yes. No Ekaya-operated component stands in the Enterprise data path, and no external model is required for production access.
“What if the model is wrong?”
The model is never the enforcement boundary. Deterministic code, scoped identity, policy checks, approval gates, and audit are.
Bring the security review.
Ekaya Enterprise is a conversation between Ekaya and your organization: what to build, where it runs, and who uses it. Tell us which data and services are in scope, where the boundary is, and who signs off.