Every authorization system starts with a simple question:<\/p>\n
Can this user perform this\u00a0action?<\/em><\/p>\n Static permissions work well for defining responsibilities inside a workspace. A signer can sign. A proposer can propose. An administrator can manage configuration.<\/p>\n That model starts to break down once a request carries\u00a0risk.<\/p>\n Consider a signer creating a withdrawal. The permission check succeeds, but that alone does not tell us much. Is the destination address new? Is the amount unusually large? Has the workspace already moved significant value today? Is the contract call attempting to grant an unlimited token allowance?<\/p>\n None of those questions are answered by the user\u2019s\u00a0role.<\/p>\n The signer may be authorized to act, yet the request itself may still deserve a different outcome.<\/p>\n That is the problem Fystack\u2019s policy engine<\/em> is designed to\u00a0solve.<\/p>\n Role-based access control is good at expressing who can perform an action. It is much less effective at expressing the circumstances under which an action should be\u00a0allowed.<\/p>\n A treasury team could create separate roles for every combination of amount, destination type, contract method, network, and time window, but that quickly becomes difficult to\u00a0manage.<\/p>\n Transaction risk is contextual. It depends on the request being made, not just the user making\u00a0it.<\/p>\n Instead of encoding operational judgment into roles, Fystack evaluates each request against the facts available at\u00a0runtime.<\/p>\n Further reading:<\/strong><\/p>\n Fystack does not replace RBAC or approvals. It separates responsibilities between three\u00a0layers:<\/p>\n RBAC<\/strong> determines who can initiate an\u00a0action.Policy<\/strong> evaluates the action\u00a0itself.Approval<\/strong> remains the human checkpoint when automation should not have the final\u00a0word.<\/p>\n The policy engine sits between permission and execution for value-bearing actions.<\/p>\n A request must first pass RBAC. Fystack then builds an evaluation payload and asks the policy engine for a decision.<\/p>\n An example of a programmable policy in Fystack, inspired by AWS policies.<\/p>\n doc := policy.Document{ engine, err := policy.CompileDocument(doc) input := map[string]any{ decision := engine.Evaluate(context.Background(), input)<\/p>\n switch decision.Effect { DENY DENY blocks the action immediately. The request never becomes a withdrawal, signing job, or any other operation that can move\u00a0assets.<\/p>\n ALLOW means the workspace has defined an explicit rule that permits the action to bypass the approval queue. The request still had to pass RBAC, and the rule still had to match the runtime facts, but no human review is required.<\/p>\n If no rule matches, the policy engine stays silent and Fystack follows the normal approval flow. This is an important distinction: no match is not an implicit allow. It simply falls back to the workspace\u2019s standard governance process.<\/p>\n When multiple rules apply, custody-safe behavior takes priority.<\/p>\n DENY > ALLOW<\/p>\n Within the same effect, declaration order provides deterministic matching so operators can identify exactly which rule produced the decision.<\/p>\n A rule follows the shape most operators already understand:<\/p>\n IF condition matches For withdrawals, conditions typically reference amount, destination, whitelist state, velocity, and\u00a0time:<\/p>\n For contract calls, the policy can evaluate method identity, contract metadata, gas parameters, and decoded calldata:<\/p>\n DENY resource.method_name == “approve”<\/p>\n DENY resource.contract_address == “0x…”<\/p>\n ALLOW resource.method_name == “transfer”<\/p>\n Before a rule is stored, Fystack validates that:<\/p>\n the trigger action\u00a0existsthe effect is\u00a0validthe condition is\u00a0presentevery referenced field belongs to the action\u00a0schema<\/p>\n Invalid policy never reaches the approval\u00a0process.<\/p>\n The evaluator receives a normalized payload regardless of action\u00a0type.<\/p>\n Every request includes workspace and action information, with additional sections such as withdrawal, wallet, resource, and context populated as\u00a0needed.<\/p>\n Evaluation follows a fixed\u00a0path:<\/p>\n Load policy bundle The result is a small decision object that answers one question:<\/p>\n Should this action be blocked, approved automatically, or continue through approval?<\/em><\/p>\n The response also contains enough context for explanation. Instead of returning a generic rejection, Fystack can identify the policy and rule responsible for the\u00a0outcome.<\/p>\n Programmable controls need governance.<\/p>\n A policy can block transactions, but it can also remove approval requirements. That makes policy changes security-sensitive operations in their own\u00a0right.<\/p>\n For that reason, policy changes follow the same review process as other high-impact actions.<\/p>\n New policies and updates are proposed as revisions rather than becoming active immediately.<\/p>\n Draft Each revision records exactly what changed, including policy fields and individual rules.<\/p>\n Reviewers can inspect both the resulting policy and the diff against the previous version before approving it.<\/p>\n Once approved, the new version becomes active, the policy version advances, and the change is recorded in the audit\u00a0trail.<\/p>\n The result is a system where both policy decisions and policy changes remain visible, reviewable, and accountable.<\/p>\n The operating model is straightforward:<\/p>\n Use roles to determine who can\u00a0act.Use policy to evaluate the\u00a0request.Use approval when the policy layer does not have an explicit\u00a0answer.<\/p>\n A treasury team might begin with only a handful of\u00a0rules:<\/p>\n DENY withdrawal.value_usd > 10000 && withdrawal.is_whitelisted == false<\/p>\n ALLOW withdrawal.value_usd < 1000 && withdrawal.is_whitelisted == true<\/p>\n DENY resource.method_name == “approve”<\/p>\n The goal is not to encode every possible decision in policy. Start with a few controls that represent obvious risk or obvious safety, then let everything else continue through the normal approval\u00a0process.<\/p>\n Over time, teams can expand policy coverage where automation adds value while keeping human review for the cases that remain ambiguous.<\/p>\n Permissions alone cannot distinguish between a routine transaction and an unusual\u00a0one.<\/p>\n In custody systems, that distinction matters. The user may be authorized, but the request still needs to be evaluated against the context in which it\u00a0occurs.<\/p>\n That is the role of\u00a0policy.<\/p>\n A signer may be allowed to create a withdrawal.<\/p>\n Whether that withdrawal should proceed is a different question.<\/p>\n Permissions can establish who is authorized to act, but they cannot evaluate the details of the request itself. By the time money is about to move, factors such as destination, amount, transaction history, contract method, and broader activity patterns may matter more than the role attached to the\u00a0user.<\/p>\n Fystack\u2019s policy engine<\/em> exists to evaluate those runtime facts before execution. It gives workspaces a way to express operational judgment explicitly, while preserving approval workflows for cases where automation should not make the final decision.<\/p>\n The result is a system that can reason about transactions, not just users, before money\u00a0moves.<\/p>\n We\u2019ve open-sourced Fystack\u2019s core Programmable Policy Engine. Explore it here: https:\/\/github.com\/fystack\/programmable-policy-engine<\/a>.<\/p>\n Have questions about your custody setup? Share what you are building via the form<\/a> and explore how Fystack\u2019s MPC wallets, KYT integrations, and consolidation engine fit your architecture.<\/p>\n Not ready yet? Join our Telegram for product updates and architecture discussions: https:\/\/t.me\/+9AtC0z8sS79iZjFl<\/a><\/p>\n Originally published at <\/em>https:\/\/fystack.io<\/em><\/a> on June 15,\u00a02026.<\/em><\/p>\n Fystack\u2019s Policy Engine: Static Permissions Meet Programmable Controls<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" Every authorization system starts with a simple question: Can this user perform this\u00a0action? Static permissions work well for defining responsibilities inside a workspace. A signer can sign. A proposer can propose. An administrator can manage configuration. That model starts to break down once a request carries\u00a0risk. Consider a signer creating a withdrawal. The permission check […]<\/p>\n","protected":false},"author":0,"featured_media":185651,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-185650","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/185650"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=185650"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/185650\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/185651"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=185650"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=185650"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=185650"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Limits of\u00a0RBAC<\/h3>\n
The Control\u00a0Model<\/h3>\n
DefaultEffect: &defaultEffect,
Policies: []policy.Policy{
{
Name: “withdrawal-approval”,
Rules: []policy.Rule{
{
ID: “block_large”,
Effect: policy.EffectDeny,
Condition: “ValueUSD > 50000”,
},
{
ID: “auto_approve_small_whitelisted”,
Effect: EffectAutoApprove,
Condition: “IsWhitelisted && ValueUSD < 5000”,
},
{
ID: “flag_medium”,
Effect: EffectFlagReview,
Condition: “ValueUSD >= 5000 && ValueUSD <= 50000”,
},
{
ID: “allow_whitelisted”,
Effect: policy.EffectAllow,
Condition: “IsWhitelisted”,
},
},
},
},
}<\/p>\n
if err != nil {
panic(err)
}<\/p>\n
“ValueUSD”: 3500.0,
“IsWhitelisted”: true,
}<\/p>\n
case policy.EffectDeny:
fmt.Println(“blocked:”, decision.Message)
case EffectAutoApprove:
fmt.Println(“auto-approved \u2014 no manual review needed”)
case EffectFlagReview:
fmt.Println(“flagged for manual review”)
case policy.EffectAllow:
fmt.Println(“allowed \u2014 requires standard approval”)
}<\/p>\nThe outcome is intentionally simple<\/h3>\n
ALLOW
NO MATCH<\/p>\nConflict Resolution<\/h3>\n
Writing Policies<\/h3>\n
THEN effect is ALLOW or DENY<\/p>\nWithdrawal Controls<\/h3>\n
Contract-Call Controls<\/h3>\n
Evaluating a\u00a0Request<\/h3>\n
\u2192 Match trigger action
\u2192 Apply wallet targeting
\u2192 Evaluate conditions
\u2192 Resolve conflicts
\u2192 Return decision<\/p>\nGoverning Policy\u00a0Changes<\/h3>\n
Revisions<\/h3>\n
\u2192 Revision
\u2192 Approval
\u2192 Active Policy<\/p>\nDiffs<\/h3>\n
Auditability<\/h3>\n
Operating the\u00a0System<\/h3>\n
Why This Matters for\u00a0Custody<\/h3>\n
Conclusion<\/h3>\n