You don't _have_ ownership of someone else's ai, and that comes with real risks.

Security risks, privacy risks, business risk.

They might rug pull you, they might charge you more, or like atrophic, silently corrupt the answers, or code...

The labs are happy to jump on any emergent capability the scaling and training impart: generate prose, teach you things, cyber security, design, code, etc.

Do you really think that the frontier labs won't turn a popular capability, or trend they notice, into a first party tool if the ROI seems there? If it's your own private ai in your datacenter, you can keep it all secret, and not lose your business.

On the bitter lesson you're right of course:), wish I had a super computer to just scale that instead.

Without diving into an experiment myself, it would be amazing if you could add some stats or experiment logs, if it's not too much problem and you have them.

For example:

Given model XYZ, every assuming 5 donors with a uniform 32GB each, each forward pass shunts xGB over the link. Each pass takes nMS, etc. etc. Resulting in n T/s, assuming latency of n ms.

Do you have such stats? Or perhaps I missed them in the repo?

Obviously they can write whatever they want in their policy documents. The thing is, sometimes this is about larger sums of money, or someones reputation, which may or may not actually lead to steps. That is in contrast with whatever TOS/EULA in account signups for some service or whatever, this feels more serious. I've seen some people getting harried after publishing something that fell _outside_ the servicing boundaries. Getting tangled up in whatever is already a loss in my book, even if you "win" in the end.

Note that that policy is also where they set out the safe-harbor conditions, which, according to my read, is tied to the bounty policy and not RD/CVD policy. The RD/CVD page itself specifies no such thing, so I relate them.

> MICROSOFT BOUNTY TERMS & CONDITIONS

> Last updated: July 23, 2025

> The Microsoft Bug Bounty Programs Terms and Conditions ("Terms") cover your participation in the Microsoft Bug Bounty Program (the "Program"). These Terms are between you and Microsoft Corporation ("Microsoft," "us" or "we"). By submitting any vulnerabilities to Microsoft or otherwise participating in the Program in any manner, you accept these Terms.

Who knows if its enforceable.

There is actually no way to give them a friendly heads up, and then do your own thing. The only way not to be bound is by not sending them any notification at all...

- "Is the code doing arithmetic in this file/function?" - "Is the code allocating and freeing memory in this file/function?" - "Is the code the code doing X/Y/Z? etc etc"

For each question, you design the follow-up vulnerability searchers.

For a function you see doing arithmetic, you ask:

- "Does this code look like integer overflow could take place?",

For memory:

- "Do all the pointers end up being freed?" _or_ - "Do all pointers only get freed once?"

I think that's the harness part in terms of generating the "bug reports". From there on, you'll need a bunch of tools for the model to interact with the code. I'd imagine you'll want to build a harness/template for the file/code/function to be loaded into, and executed under ASAN.

If you have an agent that thinks it found a bug: "Yes file xyz looks like it could have integer overflow in function abc at line 123, because...", you force another agent to load it in the harness under ASAN and call it. If ASAN reports a bug, great, you can move the bug to the next stage, some sort of taint analysis or reach-ability analysis.

So at this point you're running a pipeline to: 1) Extract "what this code does" at the file, function or even line level. 2) Put code you suspect of being vulnerable in a harness to verify agent output. 3) Put code you confirmed is vulnerable into a queue to perform taint analysis on, to see if it can be reached by attackers.

Traditionally, I guess a fuzzer approached this from 3 -> 2, and there was no "stage 1". Because LLMs "understand" code, you can invert this system, and work if up from "understanding", i.e. approach it from the other side. You ask, given this code, is there a bug, and if so can we reach it?, instead of asking: given this public interface and a bunch of data we can stuff in it, does something happen we consider exploitable?

- Did you need/use an electrician to set this up? - How much KWh capacity do your batteries have? - What about fire safety? Did you install outside, or inside? - I assume dec/jan are the months you're not fully self-sufficient, are you allowed to charge from grid to do arbitrage over time, or is that another can of worms?

I would look into:

- creating an account to run the apps you need, giving the user the password to this account, or create a shortcut to execute the browser with "runas"

Now here my ideas break down, but I think you could get far with:

- For that account, (log in as it, open IE), and configure the "secure zone" / "internet zone" as "insecure". Allow all active X components to load.

- As an admin: 1) Start/go into "Component services" (run: "DCOMCNFG") 2) Right-click "my computer" -> properties: 3) "Edit default" for both activation and access permissions and for both default and limits: 3.1) Give the new user basically all privileges. 3.2) Review if the process now works with the lower privileged user. 3.3) Reduce privileges as far as possible until the process breaks. Stop there. 4) Consider that "Remote launch" and to a lesser extent "remote access", exposes the computer to remote control _if_ the credentials for the user with those privileges are leaked. 5) Consider if this is worth the risk, if yes, leave the configuration. You're done :)

Some unconnected suggestions: - The page that loads the active X will have a number of GUIDs in them, those are the COM classes that back the active X objects (just DCOM objects). You can look those up in the registry to find the implementing .dll files, paths, etc. etc.

- You _can_ whitelist / safelist individual COM / ActiveX packages if you need to but I've forgotten the exact way to do this, and also what exactly it allows you to do ;). You may find: https://github.com/tyranid/oleviewdotnet useful to research this, it has a tab for "pre approved objects", I think if you get your ActiveX's in that list they'd be able to run under the user you need to. If you can access the HTML page you need to open which loads the ActiveX components, you can search for the CLSIDs in that tool, and perhaps figure out where they are. I'm 90% you can move the CLSIDs to a registry key to put them on the safe list, perhaps that's already enough to bypass the "local admin required".

You may be able to do the launch permissions per com object in `DCOMCNFG`.

> 2) When dealing with hostile ActiveX components, are there specific legacy behaviors (beyond obvious file/registry Access Denied) I should be looking for in my Procmon captures?

If you mean, _abused_ ActiveX components, not much you can do. Obviously yes, access to registry, etc. But if the attacker gets to a point they can load _arbitrary_ dcom objects and talk to them, it's game over, that's RCE.

If you mean, how to find which COM objects I need to allow. Better luck with `oleviewdotnet` I think. And open that page and look for the CLSIDs to know where to start. You can search in the registry and oleview to find them once you have the CLSIDs (guids).

> 3) How do you isolate this kind of hardcoded legacy requirement when there is zero budget for commercial enterprise tools?

I assume you are on a much older version of windows? Xp? 2000?, Then I'm not sure.

Used to be you needed to implement some papers to do sentiment analysis. Reasonably high bar to entry. Now anyone can do it, the result: more people doing scraping (in less competent scrapers too).

If you cannot out compete "AI SLOP" on merit over time (uptime? accuracy? dataloss?), then the AI SLOP is not actually sloppy...

If your runway runs out before you can prove your merit over that timeframe, but you are convinced that the AI is slop, then you should ship the slop first and pivot onec you get $$ but before you get overwhelmed with tech depth.

Personally, I love that I can finally out compete companies with reams of developer teams. Unlike many posters here, I was limited by the time (and mental space) it takes to do the actual writing.

If you've paid attention in the last 10 (or even 5) years as a company, and did some pentests and redteams, you've seen how you could be breached, and you took appropriate steps years ago.

A non-shoddy company will have:

- hardened their user endpoints with some sort of modern EDR/detection suite.

- Removed credentials from the network shares (really).

- Made sure random employees are not highly privileged.

- Made sure admin privileges are scoped to admin business roles (DBA admin is not admin on webservers, and vice-versa).

- Made sure everyone is using MFA for truly critical actions and resource access.

- Patched their servers.

- Done some pentests.

This won't stop the random tier 2 breach on some workstation or forgotten server still hooked up on prod/testing, but it will stop the compromise _after_ that first step. So sure, hackers will still shitpost some slack channel dumps, but they won't ransomware your whole workstation fleet...

1) What are the limitations of the scaling you do? Can I do this programmatically? I.e. send some requests to get additional pods of a specific type online?

2) What have you done in terms of security hardening? you mention hardened pods/cluster, but specifically, did you do pentest? Just follow best practice? Periodic scans? Stress tests?

I think you should not have any issues integrating with legacy AD, but know bigger enterprises have mostly moved to online IdPs. Integrating with legacy AD will make your product also likely less secure. Maybe not the way to go?

``` netsh interface ipv6 show interfaces ```

Get your interface id first, you're looking for the IDX number. There might be several.

ping ff02::1%LAN_INTERFACE_ID

So, example:

``` ping ff02::1%22 ```

Windows ping wrt the firewall is not very smart, it won't let the response packets through. So you need to disable your firewall to see systems responding.

Sadly, ping won't display the src address. It will state that "ff02::1%22" responded... But if you look in wireshark you can tell the other systems on your network received and responded to the packet.

This new functionality in Windows looks complicated. There's an architectural picture that involves:

* Multiple processes

* Windows RPC (On the basis of RPC? DCOM?)

* Handle inheritance

* Process integrity(?)

* Token privileges(?)

When UAC was introduced, there was a slew of bugs in the underlying RPC mechanism. I wonder if it will be the same. Can't wait to take a look at this in the debugger :)

I also wonder if MSRC will consider this a "security boundary". Based on the fact that the text references process integrity(UAC), and that _is not_ a security boundary, I'm going to guess not. That means that this could potentially introduce bugs, but MSRC will not be handing out bounties to fix things. Which means that any bugs people find are less likely to be reported, and more likely to find their way into ransomware down the line.

However, it's still slow as tar. When I was running the BLOOM model I think my inference time was 1 token / m.

See: https://towardsdatascience.com/run-bloom-the-largest-open-ac...