Security & Identity · Integration
Veza
Add Veza to your product for your customers, and give your AI agents governed access to it.
Veza answers a question most identity tools cannot: not who is able to log in, but what each identity can actually do once it has. It ingests permissions from applications, cloud platforms and databases, resolves them into an access graph, and lets you ask which identities can reach a given piece of data and how they came by it. It does not stop at the picture. Access reviews run against the graph, rejected access can be revoked on the target system, and joiner mover leaver automation provisions and deprovisions rather than filing a ticket for somebody else to action. That is what places this alongside identity governance rather than alongside monitoring. Custom and homegrown systems are brought in through the Open Authorization API, so a customer's own applications appear in the same graph. fastn keeps the per-tenant credentials and every call is recorded.
In your product
Embedded for your customers. Per-tenant auth, no per-customer code, maintained by fastn.
Let each customer connect their own Veza tenant, granting no more scope than the features you actually shipped consume.
Read the access graph so your product can show what an identity can reach, and which grant put it there.
Drive an access review from your product and act on what a reviewer rejected, instead of exporting a spreadsheet.
Trigger a revocation or a provisioning change through governed permissions, with every action attributable afterwards.
For your AI agents
Governed, audited access for the agents you build, through the MCP server.
An agent lists which identities can reach a sensitive dataset and traces each one back to the role or group behind it.
An agent reports what a review rejected and whether the revocation has been confirmed on the target system.
An agent proposes an access change and leaves the approval to a person, with the proposal logged either way.
Example prompt
Who can read this database in our Veza graph, and which of them got there through a group rather than a direct grant?
Set up Veza in 4 steps
- 01Enable the Veza connector in your fastn dashboard.
- 02Have each customer authorise their own Veza tenant with the narrowest scopes the features you shipped require.
- 03Map the identity, permission and review records your product uses, and enable revocation or provisioning actions only where you intend them.
- 04Call it from your product and expose the same connection to your agents through the MCP gateway.
Why teams use the Veza integration
What you get by embedding it with fastn instead of building it yourself.
- Ship a Veza integration without building it. Your customers connect their own Veza account inside your product and work their users, groups and roles there, with no per-customer code on your side.
- Handle the part that actually costs time: the blast radius of an error is large, so least-privilege and auditability are non-negotiable. fastn owns the auth, token refresh, rate limits, pagination and breaking-change fixes, so a Veza update is not your on-call problem.
- One integration serves your product and your agents. The same governed Veza connection powers in-product features and gives AI agents scoped, audited access, so you keep access and identity in step across a customer's estate without wiring it twice.
Used by these teams
Compare with
SailPoint
Okta
LumosOften used alongside
Tools the same teams tend to run next to Veza, across other categories.
ServiceNow
Datadog
PagerDuty
AWS CloudWatchVeza integration FAQ
How do I add a Veza integration to my product?
Enable the Veza connector in your fastn dashboard, then let each customer authenticate their own Veza account. fastn handles the OAuth flow, token storage and refresh per tenant, so there is no Veza client code in your app and no per-customer branch in your codebase. Setup is 4 steps.
Do my customers each connect their own Veza account?
Yes. Every connection is scoped to the individual customer, so each authorises their own Veza account and only ever sees their own users, groups and roles. That per-tenant isolation is the point of an embedded integration: you support the long tail of customer setups without maintaining an integration per customer.
Can AI agents use this Veza integration?
Yes. The same connection is exposed to your agents through the fastn MCP gateway, with permissions scoped per tenant and every call audited. An agent lists which identities can reach a sensitive dataset and traces each one back to the role or group behind it.
Who maintains the Veza integration?
fastn does. When Veza changes an endpoint, deprecates a field or alters its auth, the fix lands in the connector rather than in your backlog, and your customers' connections keep working.
What permissions does the Veza integration need?
Only the scopes required for the actions you enable. Each customer grants access to their own Veza tenant, permissions are scoped per tenant, and every call is recorded so an access change can be traced to its source.
Can access changes be automated safely?
Yes. Provisioning and deprovisioning can be driven from your product or an agent within governed permissions, with every action audited, which is what makes automated access changes reviewable after the fact.
What can I build with the Veza integration?
A common starting point: let each customer connect their own Veza tenant, granting no more scope than the features you actually shipped consume. Teams also use it for the other use cases listed above, and expose it to agents for governed reads and writes.
How much does the Veza integration cost?
It is included. Pricing is based on connected accounts, not on how many connectors you enable, so adding Veza does not change your per-connector cost. You can start free with 3 connected accounts.
Add Veza to your product
Start free with 3 connected accounts. No sales call required, and no per-customer integration code.