---
title: "ADR-010: Secure Outbound inside nr-vault"
manual: "nr-vault"
version: "1.0"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-vault:adr-010-secure-outbound@1.0"
source: "Developer/Adr/ADR-010-SecureOutboundInNrVault.rst"
rendered: "2026-09-18T07:37:50+00:00"
---

# ADR-010: Secure Outbound inside nr-vault {#adr-010-secure-outbound-inside-nr-vault}

**Table of contents**

-   [Status](https://docs.typo3.org/permalink/netresearch/nr-vault:status@1.0)
-   [Date](https://docs.typo3.org/permalink/netresearch/nr-vault:date@1.0)
-   [Context](https://docs.typo3.org/permalink/netresearch/nr-vault:context@1.0)
-   [Decision](https://docs.typo3.org/permalink/netresearch/nr-vault:decision@1.0)
-   [Consequences](https://docs.typo3.org/permalink/netresearch/nr-vault:consequences@1.0)
-   [Alternatives considered](https://docs.typo3.org/permalink/netresearch/nr-vault:alternatives-considered@1.0)
-   [Notes](https://docs.typo3.org/permalink/netresearch/nr-vault:notes@1.0)
-   [Related decisions](https://docs.typo3.org/permalink/netresearch/nr-vault:related-decisions@1.0)

## Status {#status}

Accepted

## Date {#date}

2026-01-12

## Context {#context}

We need a TYPO3-wide solution for outbound service calls that centralizes:

-   credential handling,
-   policy enforcement,
-   audit logging,
-   and (optionally) a Rust transport backend.

There are two organizational packaging options:

1.  Build a new TYPO3 extension (e.g. `t3x-nr-secure-http`) and let nr-vault consume it, or
1.  Enhance `t3x-nr-vault` directly with Service Registry + SecureHttpClient.

## Decision {#decision}

We will implement Secure Outbound **inside nr-vault** as a first-class feature:

-   `ServiceRegistryService`
-   `CredentialSetService`
-   `SecureHttpClientInterface` \+ default transport
-   Backend module extensions
-   Audit logging for outbound calls

Other extensions (nr-llm, shipping integrations, custom extensions) will depend on
nr-vault for outbound calls.

## Consequences {#consequences}

### Positive {#positive}

-   Single source of truth for secrets, ACL, and audit
-   Fewer dependency/coupling issues (no cyclic dependencies)
-   Unified backend UI for secrets + services + credential sets
-   Clear product story: nr-vault becomes the governance platform for outbound calls

### Negative {#negative}

-   nr-vault grows in scope and responsibility
-   Teams that want "HTTP only" will still pull nr-vault (acceptable given the
    primary value is governance + secrets)

## Alternatives considered {#alternatives-considered}

### Separate extension with nr-vault dependency {#separate-extension-with-nr-vault-dependency}

Create `t3x-nr-secure-http` with nr-vault as a dependency.

**Rejected** because it complicates adoption, creates unclear ownership boundaries,
and risks cycles later.

### Separate extension without nr-vault {#separate-extension-without-nr-vault}

Create a standalone extension with no dependency on nr-vault.

**Rejected** because it duplicates encryption/audit/ACL capabilities and becomes
"yet another secret store".

## Notes {#notes}

If a future scenario demands it, we can still split packages later, but the MVP
should optimize for clarity and adoption.

## Related decisions {#related-decisions}

-   [ADR-008: HTTP client](https://docs.typo3.org/permalink/netresearch/nr-vault:adr-008-http-client@1.0) \- Current HTTP client implementation (extended by this decision)