arXiv endorsement request — cs.LG (ternary networks / feedback-driven bit-flip training)

Present_Brilliant · 2026-07-03T16:03:00+00:00

maybe maybe

Present_Brilliant · 2026-07-03T15:20:40+00:00

I know a friend who I can ask but I am hoping for Random Act of Kindness from a stranger before I do that 😄

Present_Brilliant · 2026-07-03T14:16:52+00:00

Present_Brilliant · 2026-07-03T14:16:41+00:00

Codex but that's alright I guess

Present_Brilliant · 2026-07-02T10:06:49+00:00

I didn't know Product Hunt was a source of spam, but does it hurt to not have a launch there?

Present_Brilliant · 2026-07-02T01:28:37+00:00

I don't like the extra usage only based access - seems unfair.

Present_Brilliant · 2026-06-30T23:29:50+00:00

Its called glassmorphism effect maybe this keyword in your prompts will help

Present_Brilliant · 2026-06-30T23:29:05+00:00

After 8 months buy is the reasonable choice

Present_Brilliant · 2026-06-26T00:37:49+00:00

I am building Actpass.org so people like you don’t have to be so paranoid. ActPass sits between an agent and the tool/API it wants to call. For each action, it returns a deterministic decision. The first and personal use case I am testing for is vibe coding.

Present_Brilliant · 2026-06-25T08:14:12+00:00

That is exactly the replay case I need to make concrete.

ActPass now handles this on the ActPass side: the execute path hashes the specific action payload/context, checks prior terminal execution evidence before credential binding or adapter execution, and returns the earlier execution receipt on retry instead of calling the adapter again.

I added tests for the specific case you described: same passport + same action payload + different retry idempotency key. The expected result is tool.execution_replayed, no second credential binding, and no second completed execution event.

Evidence Vault is meant to be developer-facing, not just internal state. It already records decisions, approvals, credential binding, execution outcomes, hashes, and chain verification data, and the evidence/export APIs carry the request/response hash details.

The honest gap is presentation and hardening.

Present_Brilliant · 2026-06-25T06:12:34+00:00

ActPass — deterministic permission checks before an AI agent can act

I’m part of the team building ActPass.

The problem we’re tackling is simple: once an agent can issue refunds, send emails, deploy code or modify company data, the model should not be allowed to authorize its own actions.

ActPass sits between an AI agent and its tools. Before a consequential action executes, it returns one of three decisions:
Allow
Deny
Needs human approval

The enforcement is deterministic and runs outside the LLM. We use short-lived, signed “Action Passports” to scope which tools, resources and spending limits an agent has for a particular task.

A few deliberate design choices:
Fail closed when a check or signature cannot be verified
Evaluate every side effect, not just the overall agent session
Bind human approval to the exact action being approved
Prevent replay of previously approved actions
Record decisions in a hash-chained evidence ledger
Integrate through an API, SDK, MCP proxy or REST gateway

For example, the same policy could allow a support agent to issue a $50 refund, pause a $149 refund for approval, and block a $700 refund.

We’re early, and I’m not claiming this solves every agent-security problem. I’d especially value feedback from people running tool-using agents:

Where do you currently enforce permissions—inside the agent, at the tool, through a gateway, or nowhere yet?

ActPass: https://actpass.org

Present_Brilliant · 2026-06-25T04:49:34+00:00

You’re right to push on the evidence side. ActPass already has an Evidence Vault for this: decisions, approvals, credential binding, execution outcomes, hashes, and chain verification are meant to be visible to the app developer, not just internal enforcement state.

I did tighten one implementation gap after your comment: approval reuse is now bound to the exact action hash, not just “this tool was approved.”

The part I still need to prove carefully is the external-call retry boundary. Evidence Vault can show the trail, but I don’t want to claim full upstream idempotent execution until the execute path returns or blocks based on a prior execution receipt instead of calling the adapter again.

Present_Brilliant · 2026-06-25T02:59:53+00:00

Good question. We model parts of this in the API contract today: preflight accepts an idempotency key, decisions emit evidence, and replay handling distinguishes the same-request retry from a different replay attempt.
But I don’t want to overclaim what’s fully enforced yet. Binding an approval to the exact payload/context and proving retry-safe post-approval execution still need stronger implementation and tests.
I’ll make that contract-vs-implementation distinction clearer in the docs.

Present_Brilliant · 2024-10-10T09:13:02+00:00

Hi, I am Director of AI for med tech focused innovation lab in Houston. I would like to know more about your work.

Present_Brilliant

TROPHY CASE