The database password leaves the company
For Cursor to talk to PostgreSQL, someone puts the credential on a laptop. From then on the password is no longer only on your network.
GateKeeper
Agents
The model can suggest anything. It runs only what you allow.
The person has a limit. The agent, with the database password, does not.
Agents controls what each person can do in the database from Cursor or Claude. Anything past their limit happens only if someone approves it, and the company sees who asked. The database password stays with the company.
With a shared credential, the person’s limit does not apply to the agent.
The company already controls what each person does. When Cursor uses a broad PostgreSQL password, that password punches through the control: the run has no name, sensitive data opens with it, and the damage depends on a backup.
The agent inherits a wider access
With one shared, broad password, the agent reads, changes, and deletes beyond what that person would do in the database.
Sensitive data sits on the same password
Finance, payroll, and operations open together. The analyst’s agent sees whatever that password sees.
When a table disappears, the name is gone
If the credential is shared, recovery depends on a backup. The company may not know who triggered the agent, what was asked, or who let it through.
A model can look for another path when it hits a restriction. That is not authorization. The GPT-6.1 Terra report measured that behavior. The Agents limit sits outside the model, on the credential and on approval.
The agent asks. Agents decides.
An analyst asks to delete. MCP stops. Typing “approved” in the chat does not release it. The person approves in the panel, the same call runs once, and the audit keeps the names.
Agents gives the person’s limit back to the agent.
The password stays with the company. Each person comes in with a token, a role, and a data profile. What they cannot do, on the operation or on the table, waits for approval and keeps their name.
| Shared password | GatekeeperID Agents | |
|---|---|---|
| Database password | On the laptop of whoever uses the agent | On the Connector, on the company network |
| Who did it | Cannot be attributed | The person’s name in the audit |
| Query | The broad credential reads everything | Analyst and developer query what the profile can read. Everyone else asks for approval |
| Sensitive data | The same password opens finance, HR, and operations | Each profile opens only what PostgreSQL granted. The rest becomes a request |
| Create and update | Runs immediately | The developer runs it. The analyst asks for approval |
| Delete | Runs immediately | Asks for approval and runs once |
The person signs in as a role. The agent follows that role.
The role decides the operation: query, create, delete. The data profile decides the table. Both apply at the same time.
Analyst
Queries what their profile can read. Create or update becomes a request.
Developer
Queries, creates, and updates on their profile. Delete asks for approval.
Approver
Decides the requests. Does not run SQL.
Auditor
Sees who did what. Does not run SQL.
Owner
Invites the team, sets the data profile, and configures the company.
Three steps for the team
01
The Connector joins your network
It sits in front of PostgreSQL. The database is not published because of the product.
02
Each person gets a token
In Cursor, on the company VPN, only that token goes in. The database password does not go to the laptop.
03
The limit decides on the spot
What the person can do, runs. What they cannot do waits for an approver and runs once.
Frequently asked questions
Do I have to expose my database on the internet?+
No. The Connector is installed inside your company infrastructure and only opens outbound connections. The database stays on the company network, and its credentials are not sent to Gatekeeper Cloud.
How do permissions work for each role?+
Each person gets only the access their job needs.
The Developer role can query, insert, and update without approval. Destructive operations, such as deleting rows, tables, or databases, are blocked and become an approval request.
The Analyst role can query freely. Any attempt to insert, update, delete, or run another command outside that access also becomes an approval request.
The data profile is a second layer: it decides which tables that person can see. Both apply at the same time.
Can the agent see sensitive data from another team?+
Only if that person’s profile has the permission in PostgreSQL. Each profile password stays on the gateway, on the company network, and is not shown to the model.
If a query hits a table the profile cannot read, the database denies it and Agents opens a request. Someone the company names can allow that one execution, or the whole profile for a few hours or up to a day. The person who asked cannot approve their own access.
What happens when an agent tries something it is not allowed to do?+
The operation never reaches the database. The developer or analyst gets the denial and can request access, sending the same command with a reason.
The request shows up for the approver. If it is allowed, only that specific execution runs, once.
Does an approval permanently raise the person’s permissions?+
No. Approval covers only the requested command and can be used once. After it runs, the next attempt needs a new approval.
Exceptions stay exceptions. Standing access does not grow.
Does Gatekeeper get in the way of daily work?+
No. Everything the profile and the company policy already allow keeps running.
Gatekeeper steps in only when an agent tries to go past that person’s access. The run stops and becomes an approval request.
Can we tell who ran each command?+
Yes. Each person uses their own token. Gatekeeper records who called, when, what was asked, what the policy decided, and, when it applies, who approved or refused.
Sensitive details can be stored masked, so the audit does not have to expose the data that was queried.
Can access be revoked?+
Yes. Tokens expire on a term the company sets and can be revoked from the panel at any time.
The company can also raise someone’s access early, always with an end date for that grant.
What if Gatekeeper Cloud is unavailable?+
Reads, and writes the local signed policy already allows, can continue for up to 24 hours.
Destructive operations, or anything that needs a new approval, stay blocked until the connection is back. When in doubt, Gatekeeper protects the database.
Does Gatekeeper store my database password?+
Gatekeeper Cloud does not receive or store the database password. Credentials stay in the company environment and are used locally by the Connector.
Later, the Connector will also be able to read those credentials from Vault or another secrets manager.
Which technologies are supported today?+
The first version protects PostgreSQL databases reached by agents over MCP, starting with Cursor.
The architecture is ready for more databases, agents, and integrations as the product grows.