
Why Yesterday’s Guardrails Won’t Hold Tomorrow’s Agents
Some organizations are not new to credential risk at scale. They have run HashiCorp Vault in production for years. They have retired static secrets, automated rotation, and built centers of excellence around identity and access. If your AI governance pitch to an infrastructure-mature enterprise starts with “here is how to manage secrets at scale,” you have already lost the room.
The real gap for these organizations is not scale. It is speed. AI-operational enterprises have mastered running infrastructure at enterprise volume. What they have not mastered is governing decisions made by autonomous agents at machine speed, where a workflow can act, escalate, and move on before a human ever sees it.
That gap is the actual conversation infrastructure-mature organizations want to have right now. Here is what it takes to have it well.
Organizations that have been operating at scale for years do not need a primer on why credentials should not be hardcoded. They built that discipline a long time ago. Positioning a security conversation around static or even dynamic secrets treats a highly mature buyer like a beginner, and mature buyers disengage fast when that happens.
The more useful frame acknowledges what the organization has already built, then asks the next question: your governance framework was designed for infrastructure that people configure. Is it built for infrastructure that agents operate?
That reframe changes the entire conversation. Instead of “how do you protect secrets,” the question becomes “how do you govern autonomous decisions.” Those are different problems with different failure modes, and most governance frameworks in production today were never designed for the second one.
Infrastructure-mature enterprises already run committees for risk, compliance, and architectural review. The instinct is to assume agentic AI just needs another line item on an existing checklist. It does not.
Agent-driven workflows introduce a different risk surface:
Decision velocity outpaces human review. An agent operating at enterprise scale is not making one decision a human can audit in real time. It is making millions. Governance has to be designed into the architecture, not layered on as a review step after the fact.
Just-in-time credentials are necessary but not sufficient. Dynamic, short-lived credentials issued through HashiCorp Vault reduce blast radius when an agent is compromised or misbehaves. But credential hygiene alone does not answer the harder question: what is this agent authorized to decide, and how do you prove it stayed within that boundary after the fact?
Auditability has to be built for replay, not just logging. When a regulator, auditor, or board member asks “walk us through what the agent decided and why,” a log file is not an answer. Event-driven auditability, the kind that platforms like Confluent are built for, lets an organization reconstruct an agent’s decision path end to end. That reconstruction is the actual compliance artifact, not the fact that logging existed.
Vault is now an architectural decision, not an infrastructure one. Treating HashiCorp Vault as a secrets vault undersells what it does in an agentic environment. The real question it answers is how you design workflows so that a compromised or misbehaving agent has the smallest possible blast radius by design, not by luck.
The instinct with a sophisticated buyer is to assume they need less explanation. The opposite is closer to true: they need a more specific one.
A useful governance conversation with an infrastructure-mature organization covers three concrete pillars, not a generic AI risk overview:
The strongest version of this conversation never opens with a product name. It opens with a question: where do you feel the pain in AI governance today? Is it FinOps and token economics? Is it security and root-of-trust strategy? Is it operational visibility once agents start making autonomous decisions?
The product conversation comes second, and it comes framed around the pain the buyer already named. A Terraform-driven, cost-aware architecture is a stronger pitch after a FinOps pain point has been established than as an opener. The same is true of Vault’s dynamic identity model after a root-of-trust conversation, or Confluent’s event streaming after an auditability conversation. Sequence matters as much as content.
Regulators and internal audit functions are not proactively enforcing AI governance standards today. They are reactive: they show up after something goes wrong, ask what framework was followed, and expect a specific answer. That dynamic means organizations that build a defensible governance model now are the ones with an answer ready when, not if, that question comes.
This is also where the acknowledgment matters most. Infrastructure-mature enterprises are not starting from zero. They already have governance committees, architectural review boards, and risk frameworks in place. The gap is not the absence of governance. It is that yesterday’s governance frameworks were built for yesterday’s infrastructure, and agents change the assumptions those frameworks were built on.
If your organization has already retired static secrets, automated credential rotation, and built a mature root-of-trust strategy, the next governance conversation is not about doing more of the same, faster. It is about redesigning governance for a system that makes autonomous decisions instead of one that simply executes configured instructions.
That distinction, more than any single tool, is what separates organizations that are ready for the next wave of agentic AI from those that are patching yesterday’s framework onto tomorrow’s workload.
River Point Technology works with infrastructure-mature enterprises to translate AI governance strategy into deployable architecture, combining HashiCorp Vault’s identity and access model with the broader IBM ecosystem for auditability, cost governance, and compliance. Explore RPT’s approach to security and compliance, or connect with our team to assess where your current governance model has gaps your infrastructure has already outgrown.
Kevin Hospodar is Sr. Director of Go-To-Market at River Point Technology, where he leads go-to-market strategy across sales, marketing, and partnerships for RPT’s HashiCorp and IBM practices. He works closely with AI-operational enterprises navigating the shift from infrastructure automation to agentic AI governance. Connect with him on LinkedIn.
February 12, 2024 — River Point Technology (RPT), announced today that CRN®, a brand of The Channel Company, has named RPT to its Managed Service Provider (MSP) 500 list in the Elite 150 category for 2024.

The MSP 500 list compiled by CRN serves as a comprehensive guide to identifying and recognizing the top Managed Service Providers (MSPs) in North America. MSPs play a crucial role in supporting businesses by offering managed services that enhance efficiency, simplify IT solutions, and optimize return on investment.
The annual MSP 500 list is divided into three sections: the MSP Pioneer 250, recognizing companies with business models weighted toward managed services and largely focused on the SMB market; the MSP Elite 150, recognizing large, data center-focused MSPs with a strong mix of on- and off-premises services; and the Managed Security 100, recognizing MSPs focused primarily on off-premises and cloud-based security services.
The MSP 500 list aims to showcase and celebrate MSPs that are driving growth and innovation in the industry. These service providers not only enable businesses to harness complex technologies but also contribute to maintaining a strong focus on core business goals without stretching financial resources. By categorizing MSPs based on their business models and areas of expertise, the list helps end-users find the right partners to meet their specific needs and challenges in the rapidly evolving technology landscape.
River Point Technology is a recognized leader in cloud and DevOps services, supporting Fortune 500 companies in accelerating digital transformation and pushing boundaries. Our dedicated team of engineers and architects makes deploying, integrating, and managing new technology easier by providing cutting-edge custom solutions. We also help organizations achieve ongoing success and maximize the value of their technology investments through top-notch enablement programs.
Jennifer Follett, VP of US Content and executive Editor CRN, T he Channel Company, emphasized the significance of managed services for businesses at various scales, stating, “Managed services provide a route for businesses of all sizes to maintain efficiency and adaptability throughout their growth journey. The solution providers featured in our 2024 MSP 500 list are introducing cutting-edge managed services portfolios to the market, enabling their clients to achieve success by optimizing their IT budgets. This allows businesses to allocate resources strategically, concentrating on mission-critical tasks that drive future success.”

“Our core value is driving successful outcomes for our customers, so it is satisfying to see this being acknowledged by our inclusion on the CRN MSP500 list as an Elite 150 partner. I am incredibly proud of our team for their dedication and commitment to being the best in their craft which allows us to bring this value to our customers. We will continue to innovate and humanize technology by leveraging our Value Creation Technology process.” said RPT’s owner and CEO Jeff Eiben.
The MSP 500 list will be featured in the February 2024 issue of CRN and online at www.crn.com/msp500.
About River Point Technology
River Point Technology (RPT) is an award-winning cloud and DevOps service provider that helps Fortune 500 companies accelerate digital transformation and redefine what is possible. Our passionate team of engineers and architects simplify the deployment, integration, and management of emerging technology by delivering state-of-the-art custom solutions. We further position organizations to experience Day 2 success at scale and realize the value of their technology investments by offering best-in-class enablement opportunities. These include the subscription-based RPT Resident Accelerator program that’s designed to help enterprises manage the day-to-day operations of an advanced tech stack, the just-launched RPT Connect App, and our expert-led training classes. Founded in 2011, our unique approach to evaluating and adopting emerging technology is based on our proprietary and proven Value Creation Technology process that empowers IT teams to boldly take strategic risks that result in measurable business impact. What’s your vision? Contact River Point Technology today and see what’s possible.
About The Channel Company
The Channel Company enables breakthrough IT channel performance with our dominant media, engaging events, expert consulting and education, and innovative marketing services and platforms. As the channel catalyst, we connect and empower technology suppliers, solution providers and end users. Backed by more than 40 years of unequalled channel experience, we draw from our deep knowledge to envision innovative new solutions for ever-evolving challenges in the technology marketplace. www.thechannelco.com
Follow The Channel Company: Twitter, LinkedIn, and Facebook.
© 2024 The Channel Company LLC. CRN is a registered trademark of The Channel Company, LLC. All rights reserved.
The Channel Company Contact:
Kristin DaSilva
The Channel Company
curl -H "Authorization: Bearer ${TOKEN}" \
-H "Content-Type: application/vnd.api+json" \
--request POST \
-d @- \
"https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}/versions" <<EOT
{
"data": {
"type": "registry-provider-versions",
"attributes": {
"version": "${VERSION}",
"key-id": "${KEY_ID}",
"protocols": ["6.0"]
}
}
}
EOT
HashiCorp’s Terraform Cloud provides a centralized platform for managing infrastructure as code. It’s a leading provider in remote Terraform management with remote state management, automated VCS integrations, and integrations. One of its features, a private registry, can be used to develop internal Terraform providers where control, security, and customizations are paramount. An organization will want to deploy a private provider if a public is disqualified for direct upstream consumption for a specific reason. Some more specific use cases include:
Code signing guarantees that the generated artifacts originate from your source, allowing users to verify this authenticity by comparing the produced signature with your publicly available signing key. It will require you to generate a key pair through the GNU PGP utility. To develop, you can use the following command. Ensure you replace GPG_PASSWORD and your name with values that make sense.
gpg --default-new-key-algo rsa4096 --batch --passphrase "${GPG_PASSWORD}" --quick-gen-key 'Your Name <[email protected]>' default default
With your newly generated key securely stored, the next step involves exporting and uploading it to Terraform Cloud. This action facilitates verification while deploying your signed artifacts, ensuring their authenticity within the platform’s environment. The GPG Key API requires the public key to validate the signature.
To access the list of key IDs, you can execute:
gpg --list-secret-keys --keyid-format LONG.
The key is denoted in the output.
[keyboxd]
---------
sec rsa4096/<KEY ID> 2023-11-22 [SC] [expires: 2026-11-21]
You can then get your public key as a single string.
KEY=$(gpg --armor --export ${KEY_ID} | awk '{printf "%s\\n", $0}').
You’ll then need to build a payload with the output of that file and POST that to https://app.terraform.io/api/registry/private/v2/gpg-keys. The ORG_NAME is your Terraform cloud organization.
{
"data": {
"type": "gpg-keys",
"attributes": {
"namespace": "${ORG_NAME}",
"ascii-armor": "${KEY}"
}
}
}
If you plan to use this key in a CI Platform, you can also export the key and upload it gpg --export-secret-keys --armor ${KEY_ID} > /tmp/gpg.pgp to a secure Vault.
Goreleaser simplifies the process of building and releasing Go binaries. Using GoReleaser, we can bundle different architectures, operating systems, etc.
{
"version": 1,
"metadata": {
"protocol_versions": ["6.0"]
}
}
2. Configuring Goreleaser Ensure your goreleaser.yml configuration includes settings for multi-architecture support and signing. This file should live at the provider’s root, next to your main codebase.
before:
hooks:
- go mod tidy
builds:
- env:
- CGO_ENABLED=0
mod_timestamp: '{{ .CommitTimestamp }}'
flags:
- -trimpath
ldflags:
- '-s -w -X main.version={{ .Version }} -X main.commit={{ .Commit }}'
goos:
- freebsd
- windows
- linux
- darwin
goarch:
- amd64
- '386'
- arm
- arm64
ignore:
- goos: darwin
goarch: '386'
binary: '{{ .ProjectName }}_v{{ .Version }}'
archives:
- format: zip
name_template: '{{ .ProjectName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}'
checksum:
extra_files:
- glob: 'terraform-registry-manifest.json'
name_template: '{{ .ProjectName }}_{{ .Version }}_manifest.json'
name_template: '{{ .ProjectName }}_{{ .Version }}_SHA256SUMS'
algorithm: sha256
signs:
- artifacts: checksum
args:
- "--batch"
- "--local-user"
- "{{ .Env.GPG_FINGERPRINT }}"
- "--output"
- "${signature}"
- "--detach-sign"
- "${artifact}"
stdin: '{{ .Env.GPG_PASSWORD }}'
release:
extra_files:
- glob: 'terraform-registry-manifest.json'
name_template: '{{ .ProjectName }}_{{ .Version }}_manifest.json'
changelog:
skip: true
git tag 0.0.1
git checkout 0.0.1
4. Execute GoReleaser to bundle the binaries locally without publishing. We skipped publishing as we will manually upload them to Terraform Cloud.
export GPG_TTY=$(tty)
export GPG_FINGERPRINT=${KEY_ID}
goreleaser release --skip=publish


curl --header "Authorization: Bearer ${TERRAFORM_CLOUD_API_TOKEN}" \
--header "Content-Type: application/vnd.api+json" \
--request POST \
-d @- \
"https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers" <<EOT
{
"data": {
"type": "registry-providers",
"attributes": {
"name": "${PROVIDER_NAME}",
"namespace": "${ORG_NAME}",
"registry-name": "private"
}
}
}
EOT
curl -H "Authorization: Bearer ${TOKEN}" \
-H "Content-Type: application/vnd.api+json" \
--request POST \
-d @- \
"https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}/versions" <<EOT
{
"data": {
"type": "registry-provider-versions",
"attributes": {
"version": "${VERSION}",
"key-id": "${KEY_ID}",
"protocols": ["6.0"]
}
}
}
EOT
The response will contain upload links that you will use to upload the SHA256SUMS and SHA256.sig files.
"links": {
"shasums-upload": "https://archivist.terraform.io/v1/object/dmF1b64hd73ghd63",
"shasums-sig-upload": "https://archivist.terraform.io/v1/object/dmF1b37dj37dh33d"
}
# Replace ${VERSION} and ${PROVIDER_NAME} with actual values
curl -sS -T "dist/terraform-provider-${PROVIDER_NAME}_${VERSION}_SHA256SUMS" "${SHASUM_UPLOAD}"
curl -sS -T "dist/terraform-provider-${PROVIDER_NAME}_${VERSION}_SHA256SUMS.sig" "${SHASUM_SIG_UPLOAD}"
FILENAME="terraform-provider-${PROVIDER_NAME}_${VERSION}_${OS}_${ARCH}.zip"
SHA=$(shasum -a 256 "dist/${FILENAME}" | awk '{print $1}' )
# OS ex. darwin/linux/windows
# ARCH ex. arm/amd64
# FILENAME. terraform-provider-<PROVIDER_NAME>_<VERSION>_<OS>_<ARCH>.zip. Define through name_template
curl -H "Authorization: Bearer ${TOKEN}" \
-H "Content-Type: application/vnd.api+json" \
--request POST \
-d @- \
"https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}/versions/${VERSION}/platforms" << EOT
{
"data": {
"type": "registry-provider-version-platforms",
"attributes": {
"shasum": "${SHA}",
"os": "${OS}",
"arch": "${ARCH}",
"filename": "${FILENAME}"
}
}
}
EOT
The response will contain upload the provider binary to:
"links": {
"provider-binary-upload": "https://archivist.terraform.io/v1/object/dmF1b45c367djh45nj78"
}
curl -sS -T "dist/${FILENAME}" "${PROVIDER_BINARY_URL}"

credentials "app.terraform.io" {
# valid user API token:
token = "xxxxxx.atlasv1.zzzzzzzzzzzzz"
}
With the authentication bits setup, you can utilize the new provider by defining the provider block substituting in those existing variables.
terraform {
required_providers {
${PROVIDER_NAME} = {
source = "app.terraform.io/${ORG_NAME}/${PROVIDER_NAME}"
version = "${VERSION}"
}
}
}
provider "${PROVIDER_NAME}" {
# Configuration options
}
For user consumption, a common practice is to provide provider documentation for your resources utilizing Terraform plugin docs. This plugin generator allows you to generate markdowns from examples and schema definitions, which users can then consume. At the time of publication, this feature is currently not supported within the terraform cloud.
To remove the provider from the registry.
curl -H "Authorization: Bearer ${TOKEN}" \
--request DELETE \
"https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}/versions/${VERSION}"
curl -H "Authorization: Bearer ${TOKEN}" \
--request DELETE \
"https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}"
curl -H "Authorization: Bearer ${TOKEN}" \
--request DELETE \
https://app.terraform.io/api/registry/private/v2/gpg-keys/${ORG_NAME}/${KEY_ID}
Publishing custom Terraform providers to the Terraform Cloud private registry involves bundling, signing, and uploading binaries and metadata through the API. Following these steps, you can effectively manage and distribute your Terraform provider to support various architectures and operating systems.