AI Native WorkshopGo from AI experimentation to AI-native execution across your organization.
For Security and Compliance
Security Brief

A prompt
- is not a policy boundary.

An agent holding credentials acts at machine speed. A service-account log tells you which credential was used - not which agent, on whose behalf, in which session, or which approved operation ran. Qovery removes raw infrastructure credentials from the operating path and exposes a finite set of scoped operations in their place.

The model stays probabilistic. We will not tell you a wrong intent is impossible. What changes is that the operation it can request is bounded before it runs, tied to a specific principal, and reversible through a known path.

5 facts
Recorded for every operation

The agent, the human or service on whose behalf it acted, the session, the policy decision, and the resulting change.

Before
Policy is evaluated before execution, not after

Identity, role, environment and scope are checked at the API boundary. A refused call applies nothing, so there is no partial state to investigate.

Your account
Where workloads and customer data stay

Control plane and data plane are separated. Communication is encrypted and limited to the metadata and control information the architecture requires.

200+
Companies in production, including regulated sectors

Fintech, healthtech and insurance organizations run Qovery inside their own cloud accounts.

Why security teams engage with Qovery

Bounded access, complete attribution.

The claim is not that agents become predictable or that incidents become impossible. The claim is that you can say in advance what an operation may touch, afterwards who asked for it, and at any point how to reverse it.

01

No standing credentials in the agent path

  • Agents call a finite catalog of operations rather than cloud APIs
  • No keyring to store, rotate, leak or copy to a laptop
  • Scope is bound to the requesting identity and the target environment
  • An operation outside scope is refused before anything is applied
02

Attribution you can hand to an auditor

  • Each action ties to the agent, the initiating human or service, and the session
  • The policy decision is recorded alongside the resulting change
  • One log covers humans, pipelines, portals and agents
  • Evidence is exported rather than reconstructed from several systems
03

The boundary of your environment

  • Workloads and customer data remain in your cloud account
  • Control plane and data plane are separated by design
  • Traffic is encrypted and limited to required metadata and control information
  • Certification and regulatory-support claims are confirmed against current security documentation
Customer outcomes

Regulated teams in production.

Talkspace
HealthcareVirtual mental health, in production

"Previously, my SRE team needed to be extremely cautious about changes going to production. Now, we can feel much more confident."

Jack Miller - Director of SRE and Security, Talkspace
Alan
Own AWSAccount, roughly three years in production

"Qovery provided an easy-to-use interface that allowed us to manage our infrastructure within our own AWS account efficiently. It abstracted the complexities and let our developers focus on providing value to our customers."

Jean-Baptiste Barth - Infrastructure Lead, Alan
Getsafe
InsurtechRegulated insurance, own account

"Qovery provided an easy-to-use interface that allowed us to efficiently manage our infrastructure within our own AWS account."

Anar Bayramov - Staff Backend Engineer, Getsafe
Hyperline
FintechBilling platform, best practices from day one

"Within a few days, we had something running that replicates our previous setup but with multiple environments, greater control, best practices in place, extensibility, and future-proof capabilities."

Clément Garbay - Co-founder and CTO, Hyperline
Build vs. buy

Qovery vs. IAM and human approval

Authorization tools answer whether an action may happen. They do not execute it, bound its parameters, or attribute it.

With Qovery
IAM and human approval
What is evaluated
The specific operation, its scope and its parameters
Whether a principal may call an API
When
Before execution, at the API boundary
At the call, or in review afterwards
Agent identity
Agent, principal and session distinguished
One service account for all agent activity
Standing credentials
None in the agent path
Stored, rotated, sometimes copied locally
Partial failure
A refused call applies nothing
Depends where the run stopped
Reversal
A known path for supported operations
Manual, per incident
Review load
Policy absorbs the routine cases
Human approval on every change
Audit evidence
One log, exportable
Correlated across IAM, CI, cloud and chat
The questions you'll ask

Answered straight.

Agents are not safe enough for production.

Agreed, and we do not argue otherwise. The model stays probabilistic and a wrong intent remains possible. What is bounded is the operation it can request, checked before it runs and reversible after.

Our IAM and policy tooling already handles authorization.

Authorization answers whether an action may happen. It does not execute the action, bound its parameters, distinguish the agent from the service account it borrowed, or give you a reversal path when the answer was yes and the outcome was wrong.

We already require human approval on every change.

That holds until volume rises. Then approval becomes either the bottleneck or a rubber stamp. Policy should absorb the routine cases so review is spent on the exceptions.

What leaves our cloud?

Workloads and customer data stay in your account. Control plane and data plane are separated, and communication is encrypted and limited to the metadata and control information the architecture requires. Bring your questionnaire to a security review and we will answer it line by line.

Bound it before you approve it.

Bring the agent use cases currently blocked because the boundary is unclear. We will walk through what is scoped, what is attributed, what is reversible - and what is not.