展示HN：测试一个想法 – AI系统的逐决策授权层
观察
大多数人工智能架构看起来是这样的：
应用程序 → 模型 → 输出
（加上日志记录、监控，可能还有保护措施）
你可以记录模型生成的内容。
你可以过滤输出。
你可以跟踪使用情况。
但通常你无法回答：
对于这个特定的人工智能决策，它是在什么版本的政策下被允许执行的？
授权往往是系统级别的（“我们批准了部署”），而不是决策级别的。
这个区别看似微不足道，直到人工智能系统开始：
• 调用工具
• 触发工作流
• 访问内部API
• 修改状态
此时，它们不再仅仅是生成文本。
它们正在执行动作。
实验
我构建了一个薄控制层，位于应用程序和模型之间：
应用程序 → 授权层 → 模型
每个请求在执行之前都要经过OPA（开放政策代理）。
政策引擎返回以下之一：
• 重用（返回先前授权的结果）
• 计算（允许模型执行）
• 调整（根据政策修改响应）
• 升级（需要人工审核）
只有在做出这个决定后，模型才被允许运行。
存储内容
对于每个请求，系统记录：
• 政策ID和版本
• 政策包摘要（SHA-256）
• 风险领域 + 分数
• 授权决策
• 不可变账本交易ID
追踪记录是可重放的。
模型本身并不知道这个层的存在。
技术栈：
• FastAPI
• OPA
• immudb（仅追加账本）
• Docker化部署
我想验证的内容
每个决策的授权是否过度设计？
在实践中，团队依赖于：
• 提示约束
• 输出过滤
• 访问控制
• 人工审核工作流
也许这已经足够。
但如果人工智能系统变得更加自主，开始执行工具调用，我不确定事后日志记录是否足够。
云系统发展了身份和访问管理（IAM），因为“我们信任服务”并不足够。
人工智能是否需要类似的东西？
开放问题
• 你认为在大型语言模型（LLM）执行之前，运行时授权是否真的必要？
• 基于政策的决策控制在受监管行业之外是否有用？
• 不可变的可追溯性是必要的，还是仅仅日志记录就足够？
• 这将如何与代理工具调用框架互动？
我真心想知道这是否解决了一个真实的问题，还是仅仅是基础设施的过度设计。
如果有用，乐意分享更多细节。
查看原文
The Observation<p>Most AI stacks look like this:<p>app → model → output
(+ logging, monitoring, maybe guardrails)<p>You can log what the model produced.
You can filter outputs.
You can track usage.<p>But you usually cannot answer:<p>For this specific AI decision, under what versioned policy was it allowed to execute?<p>Authorization tends to be system-level (“we approved the deployment”),
not decision-level.<p>That distinction seems minor until AI systems start:
• Calling tools
• Triggering workflows
• Accessing internal APIs
• Modifying state<p>At that point, they’re no longer just generating text.
They’re performing actions.<p>⸻<p>The Experiment<p>I built a thin control layer that sits between the app and the model:<p>app → authorization layer → model<p>Every request goes through OPA (Open Policy Agent) before execution.<p>The policy engine returns one of:
• REUSE (return previously authorized result)
• COMPUTE (allow model execution)
• ADAPT (modify response under policy)
• ESCALATE (require human review)<p>Only after that decision is the model allowed to run.<p>⸻<p>What Gets Stored<p>For each request, the system records:
• Policy ID and version
• Policy bundle digest (SHA-256)
• Risk domain + score
• Authorization decision
• Immutable ledger transaction ID<p>Traces are replayable.
The model itself is unaware this layer exists.<p>Stack:
• FastAPI
• OPA
• immudb (append-only ledger)
• Dockerized deployment<p>⸻<p>What I’m Trying to Validate<p>Is per-decision authorization overengineering?<p>In practice, teams rely on:
• Prompt constraints
• Output filters
• Access controls
• Human review workflows<p>Maybe that’s sufficient.<p>But if AI systems become more agentic and start executing tool calls, I’m not sure post-hoc logging is enough.<p>Cloud systems evolved IAM because “we trust the service” wasn’t sufficient.<p>Does AI need something similar?<p>⸻<p>Open Questions
• Do you see a real need for runtime authorization before LLM execution?
• Is policy-based decision gating useful beyond regulated industries?
• Is immutable traceability necessary, or just logging?
• How would this interact with agent tool-calling frameworks?<p>Genuinely interested in whether this solves a real problem or is just infra over-design.<p>Happy to share more details if useful.