Stop Hard-Coding Security: Why Declarative, Inherited Security Needs a Platform (Not Just Policies)
- Joel Van Dyk
- 4 hours ago
- 4 min read
Most enterprise security environments still suffer from the same disease: security logic is scattered, duplicated, and inconsistently enforced across applications, platforms, and teams.
One app checks group membership one way.Another hard-codes roles in config files.A third implements its own token parsing, its own policy logic, and its own edge cases.
This is how you get drift. This is how you get gaps. And this is how you end up with “surprise” access paths no one can fully explain.
Modern cloud platforms—AWS, Azure, and GCP—solved this problem years ago with a different model:
Declarative security, inherited through a common framework, fed by a central source of identity and policy—and exposed through a standard platform layer.
If you want security that scales, that’s the model you should be using too.
Imperative Security Is the Root of the Problem
In most legacy environments, security is imperative:
Developers write code that says how to check access
Each service implements its own logic
Authorization rules live inside applications
Identity context is interpreted differently everywhere
That means:
Policy is duplicated
Behavior diverges over time
Auditing becomes a forensic exercise
Changes require code changes (and redeployments)
You never quite know if “the rule” is actually enforced everywhere
Worse: your security posture becomes an emergent property of thousands of code paths instead of a deliberate, reviewable design.
Declarative Security: Say What, Not How
Declarative security flips this around.
Instead of embedding logic, you define:
Who can access what
Under which conditions
Enforced by a shared control plane
Examples you already use:
AWS IAM policies
Azure RBAC + Conditional Access
GCP IAM
Kubernetes RBAC / admission policies
OPA / Cedar / Rego-style policy engines
You don’t write code that says how to evaluate access.
You declare the policy:
“Service A can read Resource B if it has Role X and environment is Prod.”
The platform enforces it. Consistently. Everywhere.
Inheritance: The Real Scaling Trick
The real power move is not just declarative policy—it’s inheritance.
In mature environments:
Identity comes from a central authority (IdP / IAM)
Authentication is standardized (OIDC, SAML, mTLS, workload identity)
Authorization is policy-driven and centrally governed
Every app, API, and service inherits these controls by default
This means:
Apps do not implement their own auth logic
Services do not define their own role systems
Teams do not invent their own permission models
Security becomes a platform capability, not an application feature
This is exactly how AWS, Azure, GCP, and most large enterprises work (I spent a large part of my career helping develop and then enforcing this at one firm):
Identity is centralized
Policy is declarative
Enforcement is uniform
Services consume security, they don’t reinvent it
Your internal platforms should work the same way.
The Missing Layer: An Enterprise Security API & Middleware Framework
Here’s where most enterprises stumble in practice.
You can have:
A great IdP
Beautiful policies
A solid authorization model
…and still fail if every application team has to hand-roll integrations.
What you actually need is:
A general Enterprise Security API framework: a shared middleware layer that exposes authentication and authorization as simple, consumable platform services.
Think of it as “glue” to hold your Identity environment together:
A security control plane for applications
A standard integration surface for:
Authentication
Token validation
Identity context
Authorization decisions
Policy queries
Attribute and claim resolution
Instead of every app doing this:
Parsing tokens differently
Calling the IdP differently
Interpreting claims differently
Re-implementing authorization checks differently
They do this:
“Call the security platform. Ask if this is allowed. Enforce the answer.”
That’s it.
Just like apps in AWS don’t implement IAM—they consume IAM.
Why This Matters (Especially in Real Enterprises)
In theory, this sounds obvious. In reality, there’s a brutal constraint:
Many security organizations do not have deep, scalable software engineering capacity.
So what happens?
Security publishes “standards”
Teams implement them inconsistently
Reference libraries drift
Copy-paste becomes the integration strategy
And five years later, you have 12 “standard” ways to do auth
A proper Enterprise Security API layer:
Encodes best practices once
Centralizes complexity
Gives developers a boring, stable, well-documented interface
Lets security teams improve enforcement without changing every app
Dramatically reduces the skill barrier to “doing security correctly”
It turns security from guidance into infrastructure.
What This Looks Like in Practice
A well-designed model has four layers (see the diagram):
Central Identity Source
Workforce + workload identities
Standard claims, attributes, group/role semantics
Central Policy Layer
Declarative authorization policies
Context-aware, attribute-based, environment-aware
Versioned, reviewed, testable
Enterprise Security API / Middleware
Standard authN & authZ interfaces
Token handling, context enrichment, policy evaluation
SDKs, sidecars, gateways, or service mesh integration
Opinionated, boring, reliable
Applications as Policy Consumers
They receive identity context
They ask: “Is this allowed?”
They do not own policy logic
Security becomes inherited by default, not reimplemented by exception.
Why This Is So Much Better
You get:
✅ Consistency – One policy model, one enforcement path
✅ Auditability – Policy is visible, reviewable, testable
✅ Scalability – New services inherit controls automatically
✅ Velocity – Change policy without redeploying everything
✅ Risk Reduction – Far fewer bespoke security implementations
✅ Real Zero Trust – Decisions based on identity + context, not network location
Most importantly:
You move security from “best effort per team” to guaranteed by architecture.
The Strategic Shift
This isn’t a tooling change. It’s an operating model change:
From app-owned security → platform-owned security
From imperative checks → declarative policy
From duplicated logic → inherited controls
From tribal knowledge → explicit, enforceable rules
From “standards documents” → actual security infrastructure
Cloud providers didn’t converge on this model by accident. They did it because it’s the only way security works at scale.
Bottom Line
If you want:
Fewer incidents
Faster delivery
Better audits
Real consistency
And security that doesn’t depend on every team “getting it right”
Then:
Centralize identity.Declare policy.Expose it through a security platform.Enforce it everywhere.Let everything else inherit it.
That’s what modern enterprise security actually looks like.
Comments