Encryption at rest and in transit
Protects disks, backups and the network. But it decrypts at the database connection, so your application, and every agent it serves, receives plaintext. Encryption that ends at the connection is not a control.
Ship agents on production data without exposing it.
Move your sensitive tables into Ascent with one command and connect through the drivers you already use. Each agent gets only the version of a record its policy allows, and security gets the controls and audit trail it needs to approve it.
Try the labsHands-on, synthetic data, no sign-up
Request a trialYour own instance
Prefer to talk it through? Book a demo.
Self-hosted, on your own keys. No credit card.
Transcript (79 seconds)
Ascent product overview: five core features.
One: see every AI agent with access to your data, and its blast radius before it acts. Data repository by data repository, which read modes it's allowed, who armed each token, and how much it could reach: here, forty-one thousand two hundred records, thirty-seven percent of the estate, in plaintext.
Two: permissions with real granularity. Not just what can be accessed, but under what context: who is asking, agent, person or service; which data repository, record type and tags; and conditions like multi-factor authentication, signed requests, IP ranges, countries, days and hours.
Three: when an agent oversteps, it's refused in the moment, and the reason is written down in plain language. You decide what happens next with customizable response workflows: take action directly, freeze the data repository, revoke the token, alert, or push notifications to your SIEM.
Four: agents get what the task needs, and the rest stays out of reach. The same record reads four ways: redacted, anonymized, ciphertext, or plaintext, whether it's accessed by an agent, a human, or software, through the UI, the API, the CLI, MCP, or SQL. Every one is a separately permitted, separately audited read.
Five: when the auditor comes, you hand over an evidence pack built from the hash-chained audit log: signed, framework-aware, and verifiable by anyone who presses Verify.
Ascent. A modern data control plane so you can control what AI can see and do.
You already encrypt everything. Your agents still read plaintext.
Encryption, database permissions and prompt rules each stop short of one question: what comes back when an agent asks? Here is where the real value goes today, and where it goes with Ascent.
Identity and access management, database permissions
Decide who can reach the database. Once reach is granted, the agent gets the whole row. They can't say “the last four digits, from the office network, in working hours”.
Prompt rules and output scanners
Prompt rules ask the model to behave, and a model can ignore them or be talked out of them. Scanners catch a leak after the data has left.
Ascent moves the decision from ‘can this caller reach the data?’ to ‘what comes back?’ And it makes that decision before the data reaches the AI model, so no prompt can talk its way past it.
For engineers
| Question | Encryption at rest | Ascent |
|---|---|---|
| Makes a decision on each request? | No | Yes |
| Depends on who’s asking? | No | Yes |
| Can give different answers? | No: plaintext or nothing | Yes |
| Leaves a record of the decision? | No | Yes |
In Ascent, an ordinary read returns ciphertext by default. The real value needs a separate, separately permitted action.
Show the agent the customer. Not the card number.
One stored record. On every request, policy decides which view each caller has earned: encrypted, redacted, anonymized or decrypted. A deny rule always wins. Real values are granted, never assumed.
Realistic stand-ins: the shape survives, the person does not. This is how an agent works on your data without seeing it.
emailuser_8f21@example.test
phone+1 555 010 2048
ssn000-00-2048
For engineers
Each view is its own action, permitted and logged separately:
record:getencryptedrecord:get_with_redactredactedrecord:get_with_anonymizeanonymizedrecord:get_with_decryptdecrypted
The same four apply to bulk reads, search and record history. Only fields marked encrypted are transformed; a field stored unencrypted comes back the same in every view.
Your engineers change how they connect, not how they query.
Move your sensitive tables into Ascent. One command reads your database and writes a plan you review, showing which columns are sensitive and will be encrypted; a second runs it, and both sides are checked afterwards. Your code then connects through the standard database driver for its language, and the same policy covers every other way in.
Ascent doesn’t replace your main database. It holds the sensitive records your agents need, and your transactional workload stays where it is.
Database drivers
applications
Your code connects through the standard database driver for its language and keeps its queries.
Web interface (REST)
integrations and partners
One documented interface for anything that speaks HTTP, internal or external.
MCP server
AI agents
Read-only and redacted until an operator grants each capability, per agent.
Portal and command line
people
For administrators, support, analysts and auditors, with the same limits as everything else.
For engineers
Connecting from Python, with the driver’s standard interface:
import ascent_aql
connection = ascent_aql.connect(base_url="https://ascent.example.com/api",
email="app@example.com", password="...")
cursor = connection.cursor()
cursor.execute('SELECT decrypt(firstName, age) FROM "Customer Profiles".ContactInformation '
"WHERE lastName = %s", ["Butler"])
for first_name, age in cursor.fetchall():
...Drivers for five languages, each implementing the interface that language already uses:
- Python: Python's database interface (PEP 249), plus a SQLAlchemy dialect
- Node.js: a connection and pool compatible with the pg package
- .NET: ADO.NET
- Go: database/sql
- Java: JDBC
Encrypted fields stay searchable: exact-match search works on encrypted fields, so protecting a field doesn’t cost you finding records by it.
The drivers implement each language’s standard database interface, so the decision stays reversible.
What doesn’t carry over:
- Each statement commits on its own: transactions and rollback raise an error rather than pretend.
- Schema changes and object-relational mapper migrations don't run through Ascent; an object-relational mapper's generated queries work as far as they stay within Ascent's SQL.
- Joins are inner and left equi-joins.
- A write touches at most 100 records by default, and a query with no searchable match scans at most 5,000.
Stop a misbehaving agent mid-request.
Stopped in the moment. Not reported in the morning.
For engineers: what an agent starts with, and what stops it
Every agent starts with less
Each agent gets its own identity, never a shared login. Through the Model Context Protocol (MCP) server it connects with these defaults:
- Read-only: writes and deletes are each off until an operator turns them on.
- Redacted by default; decryption is off until an operator turns it on.
- One identity per connected agent, so the audit log tells agents apart.
An automatic response, as an engineer sets it up:
triggerdecrypted reads · checked before the request completes · 30 in 60 seconds per credential
- 01Lock the datanothing more in or out
- 02Revoke the credentialthe token stops working
- 03Deactivate the agentno second credential
- 04Notify your security monitoring systemafter the lock, never before
- 05Refuse the readthe request fails
Contain first, alert second: a dead alert channel costs you the alert, never the lock. Test a response against sample data before you arm it, and choose whether a failed response fails open or closed.
Try it yourself first.
Two hands-on labs that simulate Ascent on synthetic data, open to anyone. Send the requests yourself and see what comes back, what is refused, and what gets cut off.
The containment lab
- Four agents, one set of company data
- See what comes back redacted, what is refused, and why
- Watch a misbehaving agent get cut off mid-request
The vibe coding lab
- The schema an AI coding assistant wrote
- The same SQL, six callers, six answers
- The security work you skip building
- Simulated platform
- Synthetic data only
- Nothing to install
Try the labsHands-on, synthetic data, no sign-up.
Questions buyers ask.
Does my data have to move into Ascent?
Yes, the sensitive records do. One command plans the move from an existing database and a second runs it, encrypting sensitive columns on the way in. Your applications then connect through standard database drivers.
Where does a trial run, and what data should we use?
Trial instances run on Ascent's infrastructure, set up for you alone. Use test or sample data; in production, Ascent runs in your own environment.