Building got easy. Governing didn't.
kirya maps your company's infrastructure and brings that map, rules included, to the AI tools your team uses.
An analyst needs a churn-and-revenue dashboard by region. She opens Cursor, Claude or Lovable and starts building.
No waiting for the development queue. But she is still using the company's data and infrastructure.
When everyone can build, the mess scales too.
The trouble starts when those apps enter the operation without entering IT's map.
By the time IT finds out, the company already depends on them.
Shadow AI rose from 20% to 43% of AI-related breaches worldwide (IBM Cost of a Data Breach 2026). An Amazon team described the same pattern in an internal memo in February 2026: AI was creating duplicate tools faster than the company could remove them (Business Insider, Apr 2026).
kirya connects to repositories, cloud, databases and work tools and builds a living map: systems, data and the relationships between them.
That map reaches Cursor, Claude Code, Lovable and Copilot through MCP, with access and usage rules already applied.
Whoever builds knows what already exists, which source to use and when approval is needed. What is born is registered, with an owner and a history.
Connectors today: GitHub, Azure, PostgreSQL, Google Workspace and Asana — continuously expanding.
kirya takes that request and walks the whole path: finds what already exists, prepares access, helps build and registers what is born.
Someone in the company wants to solve a problem.
kirya shows what already exists and can be reused.
Official source, sensitive data masked, permissions and approvals — all before use.
The app is born inside the rules, in kirya or in the tool the team already uses.
It comes out catalogued, with an owner and a history.
Governance before construction — without creating a new queue.
Systems, data and apps, with owners and pending approvals. And what is being built right now.
Built by the connectors, reviewed by people: relationships, owners, dependencies, activity.
Cloud and AI by area, project and app, on your key and your account. Budgets, alerts and limits: rolling out.
You choose the AI providers. The bill stays yours.
The agent gets only what the approved task needs, inside the project. Never the infrastructure credentials. What isn't on the map doesn't exist for the model.
You want the team building with AI. You also know what comes next if nobody holds the line: rework, duplication and a liability nobody mapped. kirya shows what exists, what is being built right now and who is responsible for each piece. And it puts company rules on the path of construction, not in a queue before it. The team speeds up. You can see.
Every model inference enters as pending and only becomes fact when someone responsible confirms it.
The risk is not AI. It is AI reading what it shouldn't and acting where it shouldn't. In kirya, what is not mapped does not exist for the model. The agent gets only the capability the approved task needs, never infrastructure credentials. Sensitive data is classified at ingestion and masked on every use. Every call is recorded: who asked, which rule applied, which source was used, who approved.
Who asked, which rule applied, which source was used, who approved — the trail data-protection law expects.
Data-protection law expects you to know where personal data flows, and to be able to show it. When software creation spreads across the company, that map gets lost. kirya rebuilds the map without touching content: it classifies identifiers by data structure, masks before use and keeps the processing trail regulators expect, by application, by person, by decision.
Schemas, repositories, configuration and cloud resources. Never production rows; never write access.
AI models run on the customer's own key. kirya doesn't sell tokens or sit in the billing path.
Default deny: what isn't on the map doesn't exist for the model. The agent gets what the approved task needs, never credentials.
Every inference enters as pending. It only becomes truth by a responsible person's decision.
Because they do different things. Gateways and allow-lists control where AI traffic goes. Written policy depends on people remembering it. kirya governs what AI sees and what it can do, from a map of your infrastructure that maintains itself, and records what is born from it. The three coexist. kirya is the layer the other two don't have.
To build the map, no. It reads metadata, never production rows. When someone queries data through kirya, it happens inside an explicit profile and permission, with sensitive columns masked, and it is recorded.
No. Context reaches Cursor, Claude Code, Lovable and Copilot through MCP. Technical people stay where they are. Non-technical people use the kirya interface.
It will, sometimes. That is why every inference enters as pending and only becomes truth when a responsible person confirms it. Automation is in discovery. Authority stays human.
An annual subscription, sized by what kirya governs: domains, assets and identities consuming the endpoint. Not per user. AI model consumption stays on your account. The number comes out of a thirty-minute conversation.
In 30 minutes we show how it would go through kirya: what already exists, which source is official, what gets masked, and the app being born on the map.
If it makes sense, the next step is an initial project on your infrastructure, with authorised access and clear criteria: delivery time, engineering hours, what got reused.
The invitation is for the CTO. Bring the CISO and the DPO: the guarantees were made for all three.
kirya is a Kognita platform.
kirya was born from a problem of our own. We started building software with AI faster than we could govern it, and found no tool that would map what existed without someone filling in a spreadsheet. So we built it. We are the first customer.
São Paulo, Brazil · letsgo@kirya.ai · Manifesto · Architecture