PFC Security
Most systems focus on who can enter. PFC governs what can actually happen.
See how PFC fits with Developers, How It Works, and AI Governance.
PFC evaluates execution-time authorization for every governed action that passes through the protected PFC boundary.
Zero trust at the execution boundary
No implicit trust between system components
Authority is re-evaluated per request
No standing privilege or carry-forward authorization
This is AI security built as zero trust execution, AI governance security, and runtime policy enforcement where systems must prevent unauthorized actions before they commit.
Security today protects access.
It does not fully control actions.
Once inside a system, actions are often assumed to be valid.
That assumption is where failures happen.
AI does not create risk by thinking.
It creates risk when it is allowed to act.
Every system has a point where a decision becomes real.
That point is the execution boundary.
Most architectures do not control it.
They rely on earlier checks
They trust prior steps
They assume authority carries forward
It does not.
PFC is designed to mitigate:
Unauthorized actions using valid credentials
AI-generated actions exceeding policy scope
Replay and timing attacks (nonce + timestamp enforced)
Policy drift between decision and execution
Compromised internal systems issuing valid-looking requests
PFC is designed to provide execution-governance controls in adversarial and high-consequence environments as part of a broader defense-in-depth architecture.
Internal systems are partially compromised
AI systems generate invalid or unsafe actions
Requests appear structurally valid but violate policy
Attackers attempt replay, timing, or sequencing exploits
PFC is designed for architectures that assume surrounding systems may fail or be compromised and therefore require governance checks at the protected execution boundary.
PFC sits at the execution boundary.
Every protected action should carry valid authorization at the point where downstream execution is permitted.
If required verification fails, PFC authorization is not valid for protected execution
Per-request authorization (no cached decisions)
Deterministic policy evaluation
Fail-closed execution under uncertainty
Cryptographic decision binding (Ed25519 signed receipts)
Requests that look structurally valid still require current execution-time authorization under live policy and context.
Receipts are cryptographically signed and can be verified offline without calling PFC. This allows downstream systems to continue verifying already-issued, still-valid receipts without a live verification call to PFC. Issuing new governance decisions may still depend on the availability of the configured governance service. Receipt verification details.
PFC evaluates whether an action is admissible under current conditions.
Example (simplified):
Action:
transfer_funds(amount=5000, account=A → B)
Policy:
actor.role == "authorized_operator"
amount <= actor.limit
request.timestamp within 30s
nonce unused
account not flagged
Evaluation:
All conditions must be true at execution time.
If any condition fails → request is denied.
Example request:
transfer_funds(amount=5000, account=A → B)
Evaluated at execution with:
actor.role = authorized_operator
actor.limit = 3000
request freshness = valid
nonce = unused
account = not flagged
Result: BLOCKED
Reason:
amount exceeds allowed limit
All other conditions passed, but execution is denied.
What this shows
Even with valid identity and a well-formed request, PFC can deny the governed action when it violates configured policy at evaluation time; protected downstream systems must enforce that decision before execution.
System proposes action
PFC evaluates admissibility
Authority is resolved
Action is allowed or blocked
A signed receipt is produced
What executes equals what was authorized
Request arrives at execution boundary
All conditions must be true
ALLOWED → Valid authorization returned
BLOCKED → Deny outcome returned
Signed receipt produced
Governed decisions can produce cryptographically signed evidence, and supported allow decisions can include a governance receipt for downstream verification.
This includes:
Decision outcome
Policy applied
Execution context
Authority result
Signature
A downstream verifier with the required receipt data and trusted public key can verify the cryptographic evidence independently.
Receipt verification can be performed without a live call to PFC when the verifier has the required receipt data and a trusted or pinned public key.
This is more than an application log: it is cryptographic evidence of the recorded governance decision. Whether the resulting action actually executed remains a separate fact that must be established by the protected execution path and its evidence.
A successfully verified PFC governance receipt provides cryptographic evidence that the identified PFC signing authority signed the receipt, that the signed payload matches the verified artifact, and that the artifact records the stated governance decision for that payload.
A valid receipt does not by itself prove that underlying business facts were true, that the configured policy was wise or complete, that an external human authority was legitimate outside the PFC trust model, or that the resulting real-world action actually occurred.
Cryptographic validity, policy correctness, business truth, and execution occurrence are separate questions and should remain separate in audit and security analysis.
Governed decisions preserve deterministic evidence
Supported receipts can be cryptographically verified
Replay can reproduce decisions under the recorded evaluator and policy conditions
Decision evidence is available for audit and investigation
If any of the following cannot be verified:
Authority
Policy validity
Request freshness
Signature integrity
PFC returns a deny outcome when the required validation cannot be satisfied.
A protected execution path should fail closed by requiring the configured PFC authorization before execution. PFC cannot prevent an independently reachable bypass path that does not enforce that contract.
Per-request authorization
Every governed action that uses the protected PFC path is evaluated before downstream execution rather than being admitted solely from prior state.
Fail-closed governance
If required validation fails, PFC returns a deny outcome. Fail-closed execution depends on the protected system requiring valid PFC authorization.
No standing privilege
Authority is derived fresh per request, never reused.
Tamper-evident evidence
Signed governance artifacts allow supported decision evidence to be checked for integrity and authenticity.
Replay protection
The hosted /v1/evaluate boundary rejects stale timestamps outside the allowed freshness window and rejects duplicate x-pfc-nonce reuse within the enforced gateway replay scope.
A single bad action can cause:
Financial loss
System compromise
Regulatory failure
Loss of public trust
PFC is designed to let protected systems reject actions that do not satisfy configured execution-governance requirements.
PFC enforces the policies and authority supplied to the governance layer. It does not make an incomplete policy complete or an incorrect policy correct.
Organizations remain responsible for defining appropriate policies, providing trustworthy execution context, protecting credentials and signing infrastructure, and ensuring protected systems require valid authorization before execution.
PFC can provide an enforcement and evidence layer for configured governance requirements. The organization remains responsible for deciding what those requirements should be.
PFC is an execution-governance layer. It does not replace IAM, Zero Trust infrastructure, cloud or database permissions, prompt and input defenses, model evaluation, RAG controls, sandboxing, SIEM, observability, backups, disaster recovery, human oversight, or enterprise GRC.
PFC does not guarantee that organizational policy is correct, that supplied business facts are true, or that deployment of PFC establishes regulatory compliance or certification.
Execution paths that do not require the configured PFC governance decision or valid downstream authorization remain outside the PFC enforcement boundary.
Identity and IAM: Who is requesting the action?
AI and agent controls: What is the model or agent proposing?
PFC execution governance: Is this proposed action admissible under the configured policy, authority, freshness requirements, and trusted execution context?
Downstream verification: Does this exact protected action carry the required valid cryptographic authorization?
Protected system: Should execution proceed under its configured enforcement contract?
Audit, SIEM, and GRC: What happened, and what evidence exists?
PFC complements the surrounding security stack rather than replacing it. A typical protected path is:
Governance / GRC → AI & Agent Controls → PFC Execution Governance → Downstream Verification → Protected System → Audit Evidence
This separation lets each layer answer a different security question while keeping the execution decision explicit and independently verifiable.
PFC integrates with existing systems:
Identity and access control
Zero trust architectures
AI agents and automation systems
Enterprise workflows
It can govern the protected decision point immediately before a downstream system permits a consequential action to proceed.
You do not need more visibility
You need control
PFC provides:
Enforced policy at execution
Verifiable audit records
Deterministic replay of decisions
Fail closed protection
NIST SP 800-207 (Zero Trust)
PFC's per-request governance model can support architectures applying Zero Trust principles such as explicit verification and no implicit trust. This is architectural alignment, not a claim of NIST certification or standalone conformance.
NIST SP 800-53
Maps to control families such as access control, audit logging, and system integrity through deterministic evaluation and signed decision artifacts.
Attribute-based policy models
Implements attribute-based policy evaluation using actor, request, and system state at execution time.
Traditional security asks
“Was access allowed?”
PFC asks
“Was this action allowed right now?”
Not merely monitoring
Not merely detection
Not policy on paper
Governance at the protected execution boundary, with downstream enforcement when the protected system requires valid PFC authorization.
PFC's execution-governance model is relevant where automated actions can create significant operational, financial, security, or compliance consequences:
Government and defense systems
Financial transaction systems
Healthcare and identity infrastructure
AI-driven autonomous systems
In these environments:
Detection is not sufficient
Monitoring is not sufficient
Control must be enforced before execution
See a live decision, Integrate PFC, or Understand the model.
Run It Live
Run a live evaluation. Verify the receipt yourself.