Add cross-links between IaC testing, policy, and agentic explainers

content/blog/how-to-test-infrastructure-as-code/index.md

@@ -33,7 +33,7 @@ The case for testing application code is well-established. The case for testing
 
 **Refactor safely.** Well-tested infrastructure code can be restructured, modularized, and upgraded without fear. When all your properties, tags, and security rules are asserted in tests, you know immediately if a refactor breaks a constraint.
 
-**Enforce security and compliance automatically.** Policy as code lets you encode your organization's security rules as executable tests. Mandatory policies block non-compliant deployments entirely; advisory policies surface warnings for human review. These rules run on every `pulumi preview` and `pulumi up`—not just at audit time.
+**Enforce security and compliance automatically.** [Policy as code](/what-is/what-is-policy-as-code/) lets you encode your organization's security rules as executable tests. Mandatory policies block non-compliant deployments entirely; advisory policies surface warnings for human review. These rules run on every `pulumi preview` and `pulumi up`—not just at audit time.
 
 **Ship infrastructure at software speed.** Teams that test IaC ship changes faster, with less fear. The CI pipeline becomes a confidence engine rather than a deployment gate.
 
@@ -1151,7 +1151,7 @@ jobs:
 
 ### What is infrastructure as code testing?
 
-Infrastructure as code testing is the practice of writing automated checks that validate your IaC programs before they deploy to production. Just like application testing, it includes unit tests (fast, no cloud credentials, mock the provider), integration tests (real cloud deployments in ephemeral environments), and policy checks (rules that enforce compliance standards on every preview and deploy).
+[Infrastructure as code](/what-is/what-is-infrastructure-as-code/) testing is the practice of writing automated checks that validate your IaC programs before they deploy to production. Just like application testing, it includes unit tests (fast, no cloud credentials, mock the provider), integration tests (real cloud deployments in ephemeral environments), and policy checks (rules that enforce compliance standards on every preview and deploy).
 
 ### Can you unit test IaC without deploying to the cloud?
 

content/what-is/what-is-agentic-infrastructure.md

@@ -42,7 +42,7 @@ Three things follow from this:
 
 **Agents get richer training signal.** Public Python and TypeScript include genuinely production-scale open source: real patterns at large scale, not tutorial snippets. A model that has learned from millions of Python programs brings that experience to bear when writing infrastructure code in Python. Infrastructure DSL corpora are much thinner, and skew toward documentation examples rather than production usage.
 
-**Agents can use real software engineering primitives.** Loops, functions, classes, package imports, unit tests, type checking, IDE tooling: these apply to Pulumi programs the same way they apply to application code. An agent writing a Pulumi program can import a library, write a test, refactor a module, or inherit from a base class. It's not limited to what a configuration language can express.
+**Agents can use real software engineering primitives.** Loops, functions, classes, package imports, [unit tests](/blog/how-to-test-infrastructure-as-code/), type checking, IDE tooling: these apply to Pulumi programs the same way they apply to application code. An agent writing a Pulumi program can import a library, write a test, refactor a module, or inherit from a base class. It's not limited to what a configuration language can express.
 
 **Every change is verifiable.** `pulumi preview` maps code changes to a concrete, auditable list of resource operations (what will be created, updated, or deleted) before anything in the cloud changes. An agent can verify its own output. That feedback loop (write, preview, validate, adjust) is what makes autonomous infrastructure tractable at scale. As Duffy notes: "Just as we wouldn't vibe code without git showing us the source changes, we shouldn't vibe infrastructure without a tool that shows what it will do before it does it, and what it has already done in the past." It's essentially `git diff` for your cloud.
 
@@ -94,7 +94,7 @@ Duffy frames it plainly:
 
 The layers Pulumi provides:
 
-**Policy as code.** [Pulumi Policies](/docs/iac/crossguard/) lets teams define organizational rules as code (no unencrypted storage, required tags, allowed instance types) that run on every `pulumi preview`. Non-compliant changes are blocked before they reach the cloud. Because Pulumi Policies run on the preview output, they apply whether a human or an agent proposed the change.
+**[Policy as code](/what-is/what-is-policy-as-code/).** [Pulumi Policies](/docs/iac/crossguard/) lets teams define organizational rules as code (no unencrypted storage, required tags, allowed instance types) that run on every `pulumi preview`. Non-compliant changes are blocked before they reach the cloud. Because Pulumi Policies run on the preview output, they apply whether a human or an agent proposed the change.
 
 **RBAC and entitlements.** Neo operates within the Pulumi Cloud RBAC entitlements of the user who initiated the task. It cannot escalate privilege. If a developer cannot delete a production database, Neo cannot either, regardless of what the task requests.
 

content/what-is/what-is-policy-as-code.md

@@ -38,7 +38,7 @@ Cloud misconfigurations are the leading cause of cloud security incidents. Gartn
 
 Manual policy review doesn't scale. A security team reviewing hundreds of pull requests for infrastructure changes will miss things. More importantly, by the time a human reviewer catches a misconfigured resource, a developer has already created it, someone else has built on top of it, and the blast radius of changing it has grown. Policy as code shifts enforcement left, to the same moment the infrastructure code is being written and previewed, so violations are caught before they become deployed resources.
 
-The stakes are only growing. As AI agents increasingly write and modify infrastructure, the policies that govern those modifications become the primary safety layer between automation and production.
+The stakes are only growing. As [AI agents increasingly write and modify infrastructure](/what-is/what-is-agentic-infrastructure/), the policies that govern those modifications become the primary safety layer between automation and production.
 
 ## How does policy as code work?
 
@@ -66,7 +66,7 @@ Policy as code provides five categories of benefits that address the practical p
 
 **Early validation.** Policy evaluation during `pulumi preview` means developers see violations the moment they write the code, not after the resource exists in production. The feedback loop is the same as a failed unit test: immediate, local, and easy to fix.
 
-**Best practices as versioned, testable code.** Policy packs can be published, versioned, and shared across an organization like libraries. A central platform team maintains a canonical set of compliance rules; individual product teams consume them. Policies can have unit tests, just like application code, so regressions are caught before new rules are deployed.
+**Best practices as versioned, testable code.** Policy packs can be published, versioned, and shared across an organization like libraries. A central platform team maintains a canonical set of compliance rules; individual product teams consume them. Policies can have [unit tests](/blog/how-to-test-infrastructure-as-code/), just like application code, so regressions are caught before new rules are deployed.
 
 **Consistency at scale.** Without automated enforcement, governance quality varies by team. Some teams are thorough; others are fast and skip steps. Policy as code makes the rule the same for every team, every deployment, automatically. It also integrates with cloud-native controls like AWS IAM Access Analyzer and AWS Organizations tag policies, complementing rather than replacing the native governance primitives each cloud provides.
 
@@ -211,6 +211,7 @@ Related reading:
 * [Enforcing policy as code on discovered resources](/blog/enforcing-policy-as-code-on-discovered-resources-with-pulumi/)
 * [OPA support for Pulumi Policies](/blog/opa-support-for-crossguard/)
 * [What is infrastructure as code?](/what-is/what-is-infrastructure-as-code/)
+* [What is agentic infrastructure?](/what-is/what-is-agentic-infrastructure/)
 * [What is cloud security?](/what-is/what-is-cloud-security/)
 * [What is platform engineering?](/what-is/what-is-platform-engineering/)
 * [What is DevOps?](/what-is/what-is-devops/)