Oracle powers some of the most critical workloads in the enterprise. It’s also one of the places where static, long-lived database passwords still hide in plain sight – hardcoded in config files, passed around in secrets managers, or rotated manually (or not at all).
Aembit now supports the Oracle Database protocol, bringing the same policy-driven access management you rely on for APIs and cloud services directly to your Oracle 19c and 21c databases without application developers ever needing to handle the real credentials.
What’s New
The Aembit Agent Proxy now speaks Oracle. Specifically, it intercepts the Oracle Transparent Network Substrate (TNS) wire protocol and injects real database credentials at connection time – automatically, transparently, and without touching your application code.
Here’s what that looks like in practice:
- Your application connects to Oracle exactly as it always has.
- Agent Proxy intercepts the TNS connection via transparent steering on the same Linux VM.
- Aembit retrieves the credential from the credential provider.
- The real username and password are injected into the Oracle authentication handshake (O5LOGON).
- The connection proceeds – no secrets in your config.
The only configuration change your app needs: use “aembit” as the password in the connection string.
What’s Supported
- Oracle versions: 19c (Long-Term Support through 2032) and 21c.
- Environments: AWS RDS for Oracle, containerized Oracle instances, Linux VMs (on-premises or cloud), and Docker Compose on Linux VMs.
- Languages: Java (ojdbc11/ojdbc8), Python (oracledb), Go (godror), and Node.js (oracledb) – all in thin client mode.
- TLS: Full TCPS (TCP/IP with TLS) support for both the client-to-proxy and proxy-to-database legs of the connection.
Why It Matters
Oracle databases sit at the core of ERP systems, financial platforms, and regulated workloads – exactly the environments where credential hygiene matters most and is hardest to enforce. Non-human identities (service accounts, applications, pipelines) routinely authenticate with shared, static passwords that rarely get rotated and are difficult to audit.
With Aembit’s Oracle support, every workload-to-database connection is enforced by an access policy. Credentials are fetched dynamically at connection time, never stored in application configs, and fully auditable. You get the same zero standing privilege model for Oracle that applies to AWS, Snowflake, or any HTTP-based service.
A Scenario: Securing Oracle Access in a Regulated Environment
Consider a financial services company running a Java-based reporting service on AWS. The service queries an Oracle 19c database on AWS RDS every few minutes to generate compliance reports. Until now, that connection relied on a shared database password baked into the application’s config. The password was technically stored in a secrets manager, but it was long-lived, shared across three services, and last rotated eight months ago.
With Aembit, the team deploys Aembit Agent Proxy on the same Linux VM as their reporting service and configures a Server Workload pointing to their RDS Oracle instance. They update the connection string to use “aembit” as the password. That’s the only app change.
Now, every time the reporting service opens a database connection, Agent Proxy intercepts it, fetches credentials from the credential provider, and injects it into the Oracle authentication handshake. Access is policy-enforced, and every connection is logged.
Get Started
Check out the Oracle Database setup guide in the Aembit docs to configure your first Oracle Server Workload. For a full breakdown of supported versions, client types, and details, see the Oracle protocol reference.
If you’re already an Aembit customer and running Oracle 19c or 21c on Linux, you can start today.
