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.
Data control layer for AI agents: AI needs your data. It doesn't need to see it.
Ascent is the data control layer for AI agents. Your sensitive records live in Ascent, and every request (from an agent, an application or a person) gets back only what policy allows: redacted, anonymized, or the real value. Self-hosted, on your own keys.
Book a demoTalk it through with us
Try the labsHands-on, synthetic data, no sign-up
Ready to try it on your own instance? Request a trial.
Transcript (50 seconds)
Your company said yes to AI agents. They're reading customer data, financials, and files, around the clock, faster than any team could.
Three questions nobody in the building can reliably answer.
How much can these agents reach?
What stops a rogue agent, or an employee intentionally or unintentionally misusing one?
What is the blast radius if something does go wrong, and how would you prove what happened?
Ascent: the data control plane between your agents and your data. An AI data firewall.
Agents get what the task needs. The rest stays out of reach.
See every agent's blast radius before it acts. Shut down a rogue one in the moment.
Answer the auditor in minutes, with every decision on the record as verifiable proof.
Know what they can reach. Stop what they shouldn't. Prove it.
Ascent. A modern data control plane so you can control what AI can see and do.
Your company said yes to AI agents. Can you answer three questions?
Most teams can’t. Access was granted to get the prototype working, and now it has to be justified.
For engineers
Usually the agent runs on a shared credential with production read access. Ask what that credential can reach, and the honest answer is “everything”.
You already encrypt everything. Your agents still read plaintext.
The tools you have were built for other threats. Each stops short of the question agents raise: what comes back when they ask?
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
79 seconds · see → define → enforce → use → prove
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.
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.
See what every agent can reach, before it acts.
For each agent: which records it can read, how many, and which fields would come back decrypted. Planning a role change? Rehearse it and see the difference before you make it.
For engineers
Reach runs the same decision engine that judges live requests, rather than reading configuration. Results that depend on network, time or sign-in are listed as conditional and never counted in the headline number. (Some call this an agent’s blast radius.)
Open full sizeStop a misbehaving agent mid-request.
Stopped in the moment. Not reported in the morning.
Every agent starts with less
Each agent gets its own identity, never a shared login, and connects read-only and redacted until someone grants more.
Access depends on circumstances
Same agent, same request. The answer changes with the circumstances.
WhoYour support agent
Mayread customer records decrypted
Only ifon your networkin an approved countryweekdays, working hoursmulti-factor sign-in on the sessionan approved credential
All of them hold
The record comes back decrypted, and the decision is on the record.
One of them doesn’t
Refused, or answered in a safer view. That decision is on the record too.
Rules nothing can override
A guardrail is one sentence an administrator writes once, such as “only agents from approved AI vendors ever read this data”. No role, exception or approval overrides it.
Approvals that expire
When someone needs one record this afternoon, grant exactly that: these records, this kind of read, for this long, this many times, for this reason. A grant never overrides a deny rule, and it expires on its own.
Containment
at first
Reads look normal
The agent is allowed to read these records. Nothing is wrong yet.
the limit
Too much, too fast
Thirty records in a minute from one agent. That is data being pulled out, not a task being done.
what happens
The data is locked
Nothing more comes in or goes out.
what happens
The agent is cut off
It can't reach any data until a person lets it back in.
result
That read never happens
The request that set it off is refused. No data leaves.
No black box. Every alert shows the rule that fired and the records behind it, so anyone can check the arithmetic.
For engineers
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.
Detection is rules with written-down thresholds, compared against each agent’s own history; there is no model to trust. The approved-vendor guardrail identifies the vendor by what an administrator declares on the agent’s identity, not by cryptographic proof of which model is calling.
Hand the auditor proof they can check.
Every decision is recorded: who asked, what came back, which rule decided and why. For any agent and period, export a signed evidence report. Anyone can verify it independently, and it contains no sensitive values.
For engineers
Audit records are chained so that tampering shows, and the report includes the chain proof, stating how many records predate the chain. Request values are never logged, only field names and the request’s length.
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.
Your environment. Your keys.
In production, Ascent runs inside your environment: single-tenant, or a database per customer. Use keys Ascent manages, or your own. That makes it usable where cloud products are ruled out, for regulated and sovereign workloads.
For engineers
- Your own keys, three ways: keys you hold in AWS Key Management Service, key material served from an endpoint you run, or signed key updates you push. Each data repository, a protected set of records with its own keys, rotates on a schedule, and every rotation is recorded.
- For software companies with obligations to their own customers: a workspace or data repository per customer, each with its own keys, which that customer can manage.
- The policy-writing assistant runs on a model you choose, including one on your own hardware, and sees metadata only.
Why not build it ourselves?
01
It drifts. The first service gets it right, the eighth doesn’t, and nobody can describe the whole policy when the auditor asks.
02
Two things can’t be added later. Tamper-evident records only cover what was recorded after you started, and search on encrypted fields has to be designed in before the data is written.
03
It isn’t your product. Every quarter spent building this is a quarter not spent on what your customers pay you for.
Test the build-or-buy question on your own trial instance instead of debating it.
Where teams start.
- Security
Stop a misbehaving AI agent mid-request.
Lock the data and cut the agent off before the read that crossed the line returns.
- Security
Only approved AI models near your data.
One company-wide rule names the AI vendors you trust. Nothing overrides it.
- Engineering
Let coding assistants build on data that looks real and isn't.
Coding assistants work against anonymized stand-ins of your real records.
- Both
Put AI on health, payment and HR records.
Real values stay a separate permission, and the auditor gets a signed evidence report.
- Both
Let AI agents use data without seeing it.
Agents work on redacted or anonymized data. Real values are granted, never assumed.
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.
Does Ascent scan prompts or what the model says?
No. Ascent decides what reaches the model. It doesn't filter what the model says.
Does it find sensitive data across our systems?
No. It protects the data it holds. Use a discovery tool if you need to find sensitive data elsewhere.
If we hold our own keys, can an authorized agent still read real values?
Yes, if policy grants it. Your keys protect the stored data; policy decides what each caller gets back.
What does Ascent see of our data in production?
Nothing. Ascent runs in your environment, and the policy-writing assistant works on metadata only, using a model you choose.
Does Ascent replace our database?
No. It holds the sensitive records your agents need, such as customer, payment, health or HR fields. Your transactional workload stays in your main database. Each statement in Ascent commits on its own, so it isn't built to run your transactions.