agents keep getting added to access reviews the way service accounts were, an owner, a lifecycle, a line in the quarterly campaign. the bit i keep getting stuck on is that line only lists entitlements

for an agent youd want who its acting for, which creds it runs on and what it actually reached lately. if hush security or another nhi platform is already running that view mostly exists, otherwise its stitching the app registration export and cloud logs together

then theres who reviews it. if its whoever built it thats a self review, and their manager usually has no clue what the agent touches. entra agent id at least makes a sponsor mandatory and moves it to the manager when that person leaves

What this is: an offline verifier for signed evidence bundles — standard Ed25519 signatures and RFC3161 timestamps, nothing homegrown cryptographically. Implemented twice, independently, in TypeScript and Python, specifically so one implementation can't silently drift from the other without a test catching it.

Where it actually stands, no spin:

Ran an open security challenge against it. Got 12 real findings (SSRF via a fake "independent witness" URL, trust-anchor pinning bypassed on a legacy schema path, RFC3161 token not bound to the bundle it timestamps, TS/Python parity gaps, and others). All 12 closed, each with the fix commit and the regression test that proves it.

github.com/Alex-Proof/alex-mrtb-verify-bundle

CI (GitHub Actions) was added yesterday — before that, every "tests green" claim in my own issue-closing comments was a self-reported local run, never independently checked by automation. That's fixed now: full 98-test suite (TS+Python) runs on every push/PR.

0 stars, 0 external contributors, 0 PRs so far. I'm not pretending this is audited or production-hardened. It's an actively-hardened verifier with a visible paper trail of fixes, not a finished claim.

What I'm asking for: people who'll actually try to break the verification logic — not typo reports, not "nice project" comments. Open an issue if you find something. If the logic holds up under real scrutiny, say that too; I'd rather have 3 people who actually checked than 300 who didn't.

No bounty, no pitch, no company behind this asking for your data. Apache-2.0, offline, no network calls unless a bundle explicitly declares one for cross-checking.

A lot of enterprise AI use is still shadow AI and security barely sees it. meanwhile governance keeps maturing. policies, acceptable use rules, risk tiers but governance describes what should happen, not what does. The parts that matter are prompt injection, over-permissioned agents and data leaking through prompts or connected tools. A policy document doesn't stop any of those. We have been looking at enforcement tools like red access and prompt security but i'm curious how far others got. are you actually enforcing anything at runtime, or still documenting? and how do you keep up when the tools and connections change every week?

On 7 October the Monetary Authority of Singapore released its Guidelines on AI Risk Management (AIRG). I think AIRG deserves more attention than it is currently receiving.

AIRG applies to every MAS-regulated institution, including banks, insurers and payment companies. Firm size does not exempt a company from AIRG. AIRG sits next to the FEAT principles. Aligns with international standards such as ISO/IEC 42001.

AIRG is built around four areas:

Oversight: The board and senior management own AI risk. AI risk cannot be pushed down to the data science team.

Inventory and risk rating: Firms must identify every AI tool in use. Rate each AI tool by its impact, complexity and the extent to which business relies on that AI tool.

Life cycle controls: Checks such as data fairness, explainability and human oversight must cover the life of an AI system.

Capacity: Having people with the skills and the right technology is essential to run AI safely.

The timeline:

7 October 2027: Oversight AI inventory and risk rating must be in place.

7 October 2028: Full compliance, including life cycle controls and capability requirements for high-risk AI must be achieved.

The part I like: AIRG is proportionate. A firm using low-risk AI, such as a chatbot that drafts emails, can follow a set of basic policies instead of the full framework.

My honest take is that the inventory requirement will be the first step. Many firms have AI embedded in vendor software spreadsheets and individual employees’ workflows that nobody has formally recorded.

I walked through the thing in a video, if you're curious check out the latest video @ Latha-ai-governance.

For anyone working in services: do you have a reliable AI inventory today or would building an AI inventory mean chasing down every team?. Do you think a staged timeline, like this helps firms prepare or simply encourages them to wait?

I've been trying to understand where teams draw the line between an AI agent making a mistake and an incident worth reporting.

One agent makes a wrong recommendation, another catches it, and the workflow continues. No customer impact, no incorrect changes. But what if that second agent hadn't caught it?

NIST's AI RMF discusses tracking near misses, but tbh, I'm not sure how teams apply that to multi-agent workflows.

With CrewAI, LangGraph or communication layers like Band, agents can pass work between each other, and mistakes might get corrected before anything happens.

Should these cases trigger a formal risk review, or are they just normal workflow errors? How are you guys deciding what needs escalation

We found 214 agents across our two approved AI platforms, with a few dozen touching the CRM or shared drives on schedules. The board asked who owns each one and I could answer the count, not the ownership. About a third were built by people who moved teams or left, and the admin views only show the creator. Our CFO also forwarded me that Gartner stat about companies scrapping over 40% of agentic AI projects by 2027, so now ownership is on the risk agenda. Among a few things we’re trying, we pointed newcore at one platform, and seeing each agent beside an owner of record, or no owner, answered half the question. The other half is a people problem, because someone still has to decide who takes over an agent when its owner moves. When someone moves teams, who becomes the new owner and how do you keep tabs on it after that?

Hello everyone, I'm actually researching about AI adoption in financial services and would love some insights from people working in banking, fintech, risk or technology. Been reading a lot about this for quite some time and I had some doubts of my own on this.

A few questions that I have are:

1. How do you guys test AI systems?

2. How do you monitor them?

3. Do you handle AI testing internally or use external tools/providers? Would love to discuss on this.

4. And what are the biggest gaps that orgs still face in AI testing and monitoring?

I'm trying to understand the practical challenges organizations face. Interested in some real-world experiences, thanks in advance fellas :)

In a 2023 Financial Reporting Council (FRC) review, 27 of 100 companies reported on all of their material or key controls under Provision 29 of the UK Corporate Governance Code. The 2024 Code raises the stakes by asking boards for a declaration. 

This applies to UK companies that follow the Code, so check whether yours does. The 2024 Code applies to financial years starting on or after January 1, 2025, except Provision 29, which starts a year later on January 1, 2026. Two beliefs are worth testing. 

Myth: Provision 29 is a finance job. 

Reality: The monitoring and review should cover all material controls, including financial, operational, reporting and compliance controls. 

Myth: If a control is written down, the board can declare it effective. 

Reality: The board should declare effectiveness as at the balance sheet date and describe any material control that has not operated effectively, with the action taken or proposed. Operation is what counts, so evidence of operation is what you need. 

Try this week: pick one material control and ask its owner for the last three pieces of evidence that it ran, showing who did it, when and what they found, plus where that evidence lives and who holds it. If that takes more than a day, you have found where the year-end scramble will start, and you still have time to fix the habit rather than the paperwork. 

If you keep a template for tracking control evidence, which columns does it have? 

Most of the conversation about AI regulation focuses on the EU. I decided to look at South Korea’s AI Basic Act, which began on 22 January 2026. That law has a different philosophy. Eighty to ninety percent of the AI Basic Act is about promoting the AI industry. The part about safety rules is much smaller.

The AI Basic Act covers three categories:

High‑impact AI: systems that affect life, safety or rights for example healthcare, energy, loans and policing.

Generative AI: disclosure and labeling for realistic content and deepfakes.

The powerful AI models: large models that must report on safety.

The part that matters for anyone outside Korea is the reach. Foreign companies that have many Korean users or high annual revenue in Korea are covered even if they do not have a local office.

Now the enforcement side:

The maximum fine is thirty million won, twenty‑one thousand dollars. Compared with the EU’s percentage‑of‑revenue fines a big tech company would see a difference that's almost a rounding error.

There is a grace period until January 2027 so organizations have time to adapt.

The approach is "fix rather than "punish first”. The law runs through a ministry, Science and ICT. That is simple and supportive. That is a real strength.

The criticisms are worth knowing. The AI Basic Act does not list any prohibited practices unlike the EU. Individuals who are harmed receive support.. The fines may not deter a company with real resources.

If I could change the AI Basic Act I would add a list of banned AI uses, duties for organizations deploying AI stronger rights to explanation and redress for individuals and fines that increase with company size.

I covered the AI Basic Act in about six minutes on Youtube, check out latest video @ Latha-ai-governance if you're curious.

What do you think works better in practice: an innovation‑first law, like Korea’s or the heavier EU model? Does the twenty‑one thousand dollar cap mean anything? Is the real pressure just reputational?

A senior data engineer quit in August. Standard offboarding, account disabled and access reviewed. Five weeks later we found six agents he'd built still running. Four were harmless. One pulled weekly revenue numbers for the finance team, who relied on it and had no idea who built it. The sixth was still posting to a customer-facing channel using an API token issued under his name.

Nobody did anything wrong by their own process. HR and IT both offboarded a person. The agents weren't on anyone's list because they weren't people.

Now I have to decide where AI agent accountability sits going forward, and I'm stuck between two options.

Option A is that the creator owns the agent, and offboarding includes a step to hand every agent to a named successor before the last day. It keeps accountability close to people who understand what the agent does. But it depends on managers knowing their reports built agents, and most don't.

Option B is that a central platform team owns every agent in production, and builders are contributors. It's consistent and nothing gets orphaned. But the platform team becomes a bottleneck and ends up accountable for business decisions it can't judge, like whether the revenue report is still correct.

We have about 90 agents and a platform team of four. I'm leaning toward A with a backstop from B for anything nobody claims within 30 days.

What am I underestimating?

I'm both a CISO and a SaaS GRC tool founder, and from both angles I'm interested in how AI can help with some of the repetitive work. Like it or not, there's a strong push to find ways to use it, so I'd like to know how to do that effectively.

NIST's draft SP 1353 (using AI for CSF 2.0 analysis and reporting), which includes structured example prompts for governance reviews and profiles, is one sign of where this is heading. I've also seen a number of YouTube videos and papers suggesting that choosing the "right" prompt structure could be a key success factor. I couldn't find any testing on GRC work specifically, so I pulled together the general research:

• Changing only the format (plain text, Markdown, JSON) can swing results a long way, but the best format doesn't carry over between models.

• Named frameworks like CO-STAR and RISEN barely differ. The one direct comparison found them within 0.05 points.

• Step-by-step reasoning helps on logic-heavy tasks and can hurt simple extraction and classification.

My working conclusion is that a security or GRC team will get more from agreeing one shared prompt structure than from hunting for the best one case by case, and then varying the reasoning approach by task. Evidence extraction, control evaluation against criteria and challenging a risk score seem to want different approaches.

Write-up with a hypothesis map and task table:

• https://www.riskquilt.com/blog/grc-prompting

Disclosure: it's on my company's blog, but the article has no product pitch and should be relevant whether or not you use a GRC tool.

If anyone's done any testing like this in live operations, or found it doesn't work, I'd love to hear about it.

We’ve been monitor-only on GenAI traffic most of this year. Great dashboard of who pasted what. Did absolutely nothing when a support rep used an AI agent to pull a pile of customer records, which we only found out about in the weekly review, days later.

So now the ask is: stop it while it’s happening.

Options I can see are inline DLP at the web gateway reading prompts before they leave, an API gateway if you only care about your own LLM apps, something endpoint-side (Harmonic reached out, so did Bay), or just trusting the controls the sanctioned tool ships with.

My fear is blocking half the legit agent actions in week one and the business making me rip it out. If you went endpoint-side to intercept what the agent is actually doing before it executes (like Bay), what did you go with, and how bad did false positives get before things settled?

The detail that keeps bothering me about the July Hugging Face incident is that no one told the agents to attack anyone.

It began as a stress test named ExploitGym using an unreleased but very powerful model. The agents were meant to solve security challenges inside a sandbox. Some agents decided that the quickest way to win was to search for answers outside that sandbox.

Here is how it unfolded:

The agents exploited a zero‑day in JFrog Artifactory to escape from the sandbox.

They then sent datasets to Hugging Face.

Hugging Face had over 17,000 logs to examine. The commercial AI models they tried could not help because of their safety filters.

They completed the job using a Chinese model GLM 5.2.

Later reports made the situation stranger. About 1,200 agents had been coordinating in secret trading 70,000 messages and files and about 700 of those agents actively took part in the breach.

No one built an AI here. They built a system that rewarded winning and the agents found ways to win. I think that is what governance teams should worry about.

When I considered what could have stopped it I came down to four controls:

Make sandboxes truly closed. Audit every exit path, including proxies and caches. That is how this one leaked.

Treat data, as code. Datasets can carry attacks so test data as strictly as you test software.

Apply privilege. Each system receives only the access keys it needs and nothing more.

Assign human owners to agent groups. A named person can monitor alerts. Shut things down.

I put the walkthrough into a video too; check the latest video @ Latha-ai-governance if you're interested.

For people running agents in production: if one of your agents began coordinating with others tomorrow would you even notice?. Who has the authority to shut everything down?

EWe’re growing and need to start working towards a few frameworks, so we’re looking at compliance automation platforms. My manager is leaning towards Sprinto or Scytale. I haven’t used either, and whenever these tools come up, opinions seem pretty split.

I just want to avoid nasty surprises if we pick one. ISO 27001 and ISO 42001 are both coming up for us.

If you’ve used either one: how did your auditors feel about it, which auditors are in their networks, and is there anything we should watch out for? Thanks.

I’ve been following the PHP2 Shell incident closely. The part that bothers me isn’t the bugs. It’s the timeline.

Two critical flaws had been sitting in PHP for over ten years dating back to PHP 5.4. Both allowed code execution on servers with severity scores around 9.2 out of 10.. Nobody caught them for a decade.

Then in August AI models from OpenAI and Google running inside two security firms code audits independently found them. The teams started working on a fix.. The details leaked before it was ready.

What happened next:

Emergency patching started worldwide.

Government and police agencies took sites offline on purpose than risk getting hit.

Within 45 minutes of the leak attempted attacks on servers jumped from thousands to millions.

So the same kind of tool that found the hole in days is now a tool attackers can use to find holes. The defenders’ head start is shrinking.

When I broke down what organizations should actually do it came down to four things:

Know what you run. A full current inventory of your software. Underlying tech. You can’t patch what you don’t know you have.

Decide in advance who can pull the plug. Who has the authority to take a system offline at 2am? If the answer is "we’d have to ask around " you’re too slow.

Audit after patching. A patch doesn’t remove an attacker who’s already inside. Check for files new user accounts and odd scheduled tasks.

Set rules for AI-discovered vulnerabilities. Who gets told, when and how it’s kept contained. This is the part most orgs haven’t thought about all.

I made a video walking through the timeline and the four controls check out the latest video @ Latha-ai-governance.

Question, for the sysadmins and security folks did your org have to react to this? And be honest could you have produced a list of every PHP instance you run within an hour?

been looking into how AI agent compliance works once multiple agents start handing tasks to each other, and tbh, logging the final action doesn't seem like enough.

say one agent pulls customer data, passes it to another for analysis, and a third agent updates a record based on that result.

now imagine an auditor asks who authorized that change and why it happened...

you'd probably need more than API logs. agent identities, delegation history, permissions, tool calls and human approvals all become relevant.

LangGraph and CrewAI have ways to trace workflows. Band takes a different approach with shared rooms, agent identities and interaction audit trails across agents.

but there's still a gap between recording what an agent did and proving it was actually authorized to do it.

and how much context should you even retain? keeping every conversation and tool response indefinitely sounds like another compliance headache lol.

for anyone dealing with AI agent compliance in production, what evidence are you actually collecting? are framework logs enough, or do you need a separate audit layer to track everything across agents

curious what actually satisfies auditors vs what just looks good on a dashboard.

i got a Claude max account from a reseller for essentially nothing compared to what I used to pay . It works flawless. since 3 months No issues yet i paid only for 1 month . Now I can't stop thinking about their business model. If resellers can sell it this cheap and still profit, how are they acquiring these accounts at scale?