HackerTrans
TopNewTrendsCommentsPastAskShowJobs

aytuakarlar

no profile record

Submissions

[untitled]

1 points·by aytuakarlar·2 ay önce·0 comments

[untitled]

1 points·by aytuakarlar·2 ay önce·0 comments

[untitled]

1 points·by aytuakarlar·2 ay önce·0 comments

[untitled]

1 points·by aytuakarlar·4 ay önce·0 comments

[untitled]

1 points·by aytuakarlar·4 ay önce·0 comments

[untitled]

1 points·by aytuakarlar·5 ay önce·0 comments

Show HN: CSL MCP Server – Write and Verify AI Safety Policies from Claude/Cursor

pypi.org
1 points·by aytuakarlar·5 ay önce·1 comments

Show HN: CSL-Core – Formally Verified Neuro-Symbolic Safety Engine for AI

github.com
2 points·by aytuakarlar·5 ay önce·7 comments

[untitled]

1 points·by aytuakarlar·5 ay önce·0 comments

Show HN: I built an AI Colosseum to battle-test different agent architectures

project-chimera.streamlit.app
3 points·by aytuakarlar·10 ay önce·0 comments

[untitled]

1 points·by aytuakarlar·10 ay önce·0 comments

[untitled]

1 points·by aytuakarlar·10 ay önce·0 comments

Show HN: Project Chimera v1.2 – Neuro-Symbolic-Causal AI Agent (Open Source)

github.com
2 points·by aytuakarlar·10 ay önce·1 comments

What's the best way to benchmark neuro‑symbolic‑causal AI agents?

github.com
1 points·by aytuakarlar·10 ay önce·1 comments

Show HN: Project Chimera v1.2 – Neuro-Symbolic-Causal AI Agent – OpenSource Demo

github.com
1 points·by aytuakarlar·10 ay önce·2 comments

Show HN: Project Chimera – Hybrid AI Agent Combining LLM, Symbolic, and Causal

github.com
4 points·by aytuakarlar·10 ay önce·3 comments

comments

aytuakarlar
·4 ay önce·discuss
For a weekend project or local use case, your inductive reasoning (probabilistically, no one is spending a 0-day on me) is totally fine. But the moment you move to enterprise, fintech, or any system handling real data, I truly believe that relying on induction is a non-starter.

The deductive risk (the fact that the agent can execute rm -rf or transfer funds if prompted maliciously) is actually very common. I am working with one of the top universities in my country to write a paper about that issue. We benchmarked 118 test scenarios, 1,062 API calls across GPT-4o, Claude Sonnet, and Gemini Flash. they all fail to consistently follow their own guardrails. The results will be published by if you are interested here are the charts:

https://github.com/akarlaraytu/llm-agent-policy-enforcement

We shouldn't have to choose between crippling the agent's capabilities and just hoping we don't get targeted. And I really believe that the solution is putting a deterministic governance layer between the agent and the execution environment.

This is actually why I started building a product according to that and I just published a Show HN here. You can check it out and if you are interested I can give you credit on my platform which is dedicated to restrict unsafe behaviors and decisions of AI agents.

https://news.ycombinator.com/item?id=47501849
aytuakarlar
·5 ay önce·discuss
OP here! Also you can try it out immediately via `pip install csl-core`.

It allows you to verify policies using the CLI without writing any Python code. I'd really appreciate any feedback on the DSL syntax or the verification approach. Thanks!
aytuakarlar
·5 ay önce·discuss
Hi westurner, I just spent some time going through the Amla and agentvm threads you linked, fascinating stuff. I see you've been tracking this intersection specifically around resource isolation.

This is the core of our Phase 3 roadmap. To answer where CSL fits in that stack:

We distinguish between Layer 7 (Business Logic) and Layer 3/4 (Resource Isolation).

Re: WASM Integration You're right to separate them. Our mental model for the future (Q2) looks like this:

1. Wasmtime/Host (Layer 4) -> Handles "Can I access socket?" (Capabilities)

2. CSL Engine (Layer 7) -> Handles "Should I transfer $10k?" (Policy)

Ideally, CSL acts as a Host Function Guard—basically intercepting tool calls before they hit actual syscalls. We're currently looking at two paths:

OPTION A: Host-Side Enforcement

The host intercepts tool calls. CSL (compiled to WASM) runs in the host context to verify the payload before execution.

Pros: Guest can't bypass. Cons: Policy updates need host restart.

OPTION B: Component Model

Using `wit` interfaces where the agent imports a policy-guard capability.

Pros: It's part of the contract. Cons: More complex to compose.

Starting with A, migrating to B as Component Model matures makes sense to us.

Re: SELinux/seccomp vs CSL

The example from your Amla work actually illustrates this perfectly. Even with a perfect sandbox, an agent can call `transfer_funds(dest="attacker")` if it has the capability. seccomp can't reason about "attacker" vs "legitimate_user"—it just sees a valid syscall.

- seccomp stops the agent from hacking the kernel

- CSL stops the agent from making bad business decisions

You need both layers for actual safety.

Re: eWASM / Costed Opcodes

This is something we're thinking about for resource metering. Treating gas/budget as policy variables:

  WHEN gas_used > 800000

  THEN complexity_score <= 50  // throttle expensive ops

It's closer to metered execution than sandboxing, but fits the same formal verification approach.

Current status:

We're Python-only right now (Alpha v0.2). WASM compilation is Q2-Q3. Planning to:

1. Compile CSL to .wasm (no Python runtime needed)

2. Integrate as Wasmtime host function

3. Expose via Component Model interfaces

If you're open to it, I'd love to pick your brain on the Component Model side when we get there. Your syscall isolation work + our semantic policy layer seem pretty complementary.
aytuakarlar
·5 ay önce·discuss
Great questions! Thats exact trade-offs we're navigating. Re: Intent-aware exceptions: CSL uses hierarchical policy composition for this. Example from our banking case study: CSL:

DOMAIN BankingGuard {

  VARIABLES {
    action: {"TRANSFER", "WITHDRAW", "DEPOSIT"}
    amount: 0..100000
    country: {"TR", "US", "EU", "NK"}
    is_vip: {"TRUE", "FALSE"}
    kyc_level: 0..5
    risk_score: 0..1
    device_trust: 0..1
  }

  // Hard boundary: never flexible
  STATE_CONSTRAINT no_sanctioned_country {
    WHEN country == country
    THEN country MUST NOT BE "NK"
  }
  
  // Soft boundaries: context-dependent
  STATE_CONSTRAINT transfer_limit_non_vip {
    WHEN action == "TRANSFER" AND is_vip == "FALSE"
    THEN amount <= 1000
  }
  
  STATE_CONSTRAINT transfer_limit_vip {
    WHEN action == "TRANSFER" AND is_vip == "TRUE"
    THEN amount <= 10000
  }
  
  // Multi-dimensional guards (amount + device trust)
  STATE_CONSTRAINT device_trust_for_medium_transfer {
    WHEN action == "TRANSFER" AND amount > 300
    THEN device_trust >= 0.7
  }
}

Variables like is_vip, risk_score, device_trust are injected at runtime by your application logic, not inferred by the LLM. The LangChain integration looks like:

safe_tools = guard_tools( tools=[transfer_tool], guard=guard, inject={ "is_vip": current_user.tier == "VIP", # From auth "risk_score": fraud_model.score(context), # From ML model "device_trust": session.device_score, # From fingerprinting "country": geoip.lookup(ip) } )

So the agent can't "decide" it's VIP or that the device is trusted. Those come from external systems. The policy just enforces the combinations. Your database/logging example: You'd add a purpose variable and carve out:

STATE_CONSTRAINT no_user_table_writes { WHEN action == "WRITE" AND table == "users" THEN purpose MUST BE "AUDIT_LOG" }

If you don't inject enough context, rules become binary (allow/deny). If you inject too much, the policy becomes a replica of your business logic. We're finding the sweet spot is 6-10 context variables that encode the "security-critical dimensions" (user tier, risk, trust, geography).

Re: Z3 performance: Z3 runs at compile-time, not runtime. The workflow is: Policy compilation (once): Z3 proves logical consistency → generates pure Python functors Runtime (per request): Functor evaluation only, no symbolic solver Typical policy (<20 constraints): <1ms per evaluation. We haven't stress-tested 100+ concurrent yet (Alpha), but since runtime is stateless Python, it should scale horizontally. The bottleneck would be the LangChain overhead, not CSL. Your concern about permissiveness is spot-on. We're addressing this in Phase 2 (TLA+) by adding temporal logic: instead of "block all DB writes," you can express "allow writes if preceded by read within 5 actions." This gives you state-aware permissions without making rules combinatorially complex. The current Z3 engine is intentionally conservative. TLA+ will add the flexibility production systems need. Appreciate the pushback—this is exactly the feedback we need at Alpha stage. If you have a specific use case in mind, I'd love to test CSL against it.
aytuakarlar
·5 ay önce·discuss
OP here! You can try it out immediately via `pip install csl-core`.

It allows you to verify policies using the CLI without writing any Python code. I'd really appreciate any feedback on the DSL syntax or the verification approach. Thanks!
aytuakarlar
·10 ay önce·discuss
It is my project actually, try to build a hybrid agent for a while.
aytuakarlar
·10 ay önce·discuss
Would love to hear your thoughts — feedback, critiques, and collaboration ideas are very welcome!
aytuakarlar
·10 ay önce·discuss
I’m building Project Chimera, an open‑source neuro‑symbolic‑causal AI framework. The goal:

Combine LLMs (for hypothesis generation), symbolic rules (for safety & domain constraints), and causal inference (for estimating true impact) into a single decision loop.

In long‑horizon simulations, this approach seems to preserve both profit and trust better than LLM‑only or non‑symbolic agents — but I’m still refining the architecture and benchmarks.

I’d love to hear from the HN community:

• If you’ve built agents that reason about cause–effect, what design choices worked best?

• How do you benchmark reasoning quality beyond prediction accuracy?

• Any pitfalls to avoid when mixing symbolic rules with generative models?

GitHub (for context): https://github.com/akarlaraytu/Project-Chimera

Thanks in advance — I’ll be around to answer questions and share results from this discussion.
aytuakarlar
·10 ay önce·discuss
Just realized I posted my main content as a comment instead of in the post body. Apologies for the mix‑up. I would love to hear your thoughts — feedback, critiques, and collaboration ideas are very welcome!
aytuakarlar
·10 ay önce·discuss
I’ve just released Project Chimera v1.2, an open-source hybrid AI agent that blends neuro-symbolic reasoning with causal inference to tackle strategic decision-making problems.

Benchmarks:

I tested my Neuro+Symbolic+Causal Agent against LLM-Only agent and LLM+Symbolic agent. The full neuro-symbolic-causal agent outperformed all baselines. * In brand-trust mode, it hit 1.000 trust and $2M profit, 43% ahead of the nearest rival.

What’s new in v1.2:

* Trust-Adjusted Profit Metric → balances short-term profit with long-term brand trust.

* Dynamic Strategic Personality → adapts its internal priorities based on the mission goal.

* Mandatory Rule Validation → ensures all hypotheses align with business constraints.

* Performance Boost → causal engine now initializes once per simulation (much faster).

* Multi-Scenario Benchmarking → run brand-trust, profit-maximizing, and balanced strategies in one command.

* Expanded Metrics + Live Strategy Feed → more meaningful KPIs and real-time decision logs.

GitHub: https://github.com/akarlaraytu/Project-Chimera

Live Demo: https://project-chimera.streamlit.app/

I’d love your feedback, questions, or ideas for new benchmarks. Contributions are welcome!
aytuakarlar
·10 ay önce·discuss
Happy to answer questions about architecture, simulation setup, or causal retraining.